Ich habe heute das schlechte Wetter genutzt und neue Zeit-Features ins Modul eingebaut.
1. Zeitraster wie hier beschrieben
Beispiele:
[+:MM] MM sind Minutenangaben zwischen 1 und 59
Beispiele:
[+:30] zur vollen und zur halben Stunde
[+:10] um XX:00 XX:10 XX:20 XX:30 XX:40 XX:50
[+:15] um XX:00 XX:15 XX:30 XX:45
usw.
[:MM] MM sind Minutenangaben und können zwischen 00 und 59 sein.
Beispiele:
[:00] zur vollen Stunde
[:05] immer fünf nach
[:15] immer viertel nach
[:30] immer um halb
usw.
[+[h]:MM] mit: h sinnvollerweise zwischen 2 und 23 und MM zwischen 00 und 59
Beispiel:
[+[2]:10] um 00:10 02:10 04:10 06:10 08:10 usw.
2. Rechnen mit Zeit: Beliebige Perlausdrücke in Kombination mit Zeitangaben im üblichen Format: HH:MM, Readings oder Stati sowie Perlfunktionen.
Beispiele:
relative Zeitangaben in Sekunden: Trigger alle 100 Sekunden
DOIF ([+100]) (set bla on)
absolute Angaben in Sekunden: 7200 Sekunden nach Mitternacht:
DOIF ([7200]) (set bla on)
Sekundenangaben über Stati oder Readings:
define Zeit dummy
set Zeit 300
Hier 300 Sekunden nach Mitternacht:
DOIF ([[Zeit]]) (set bla on)
Hier in 300 Sekunden:
DOIF ([+[Zeit]]) (set bla on)
Dast Setzen des Dummys Zeit wird sofort im Modul berücksichtigt, z. B.
[set Zeit 00:10
Zeitberechnungen:
Berechnungen werden in runde Klammern gesetzt. Es können beliebige Ausdrücke der Form HH:MM mit Sekundenangaben in Rechenoperationen (was Perl so hergibt) kombiniert werden. Sie können direkt angegeben werden oder aus Funktionen, Stati oder Readings kommen.
Zeitangaben mit Perlfunktionen: Sunnenuntergang um bis zu 10 Minuten zufällig verzögern:
DOIF ([({sunset()}+int(rand(600)))]) (set bla on)
Kombination aus Zeitangaben und Sekundenangaben: Zufällige Verzögerung bis zu 10 Minuten nach 10:00 Uhr
DOIF ([([10:00]+int(rand(600)))]) (set bla on)
Kombination aus Stati oder Readings mit Sekundenangaben:
define Zeit dummy
set Zeit 10:00
DOIF ([([Zeit]+int(rand(600)))]) (set bla on)
oder relative Angaben: hier wird alle 5 Minuten getriggert
set Zeit 00:01
DOIF ([+([Zeit]+[00:04])]) (set bla on)
Hier eine Kombination mit Zeitintervallen: Hier von 09:55 bis 10:05 am Freitag
set Zeit 10:00
DOIF ([([Zeit]-[00:05]) - ([Zeit]+[00:05])]|5]) (set bla on)
Hier noch mal mit Zufall beeinflusst:
DOIF ([([Zeit]-[00:05]- int(rand(300))) - ([Zeit]+[00:05]+int(rand(300)))]|5]) (set bla on)
Man kann beliebig Zeitangaben mit Perlfunktionen und Readings bzw. Stati kombinierten. Da auch hier der Perlinterpreter zum Zuge kommt, sind die Möglichkeiten Zeit zu berechnen unbegrenzt.
Alles ist natürlich abwärtskompatibel zum bisherigen Modul.
Edit: Diese Version wurde bereits eingecheckt.
Gruß
Damian
Hallo damian
danke für dein super Modul und die. Erweiterung
Cool. Aktuell sehe ich persönlich zwar nichts, wo ich es brauchen würde, aber ich bleibe mal dran und werde ggf. ein bisschen testen...
Yippih! Dann könnte ich ein weiteres AT ersetzen (alle 15 wird ein Routine aufgerufen, der den Vorlauf meiner Heizung auf den Bedarf anpasst).
Christian
ich habe so das gefühl, dass FHEM bald DOIF heisst. ;)
Zitat von: frank am 30 März 2015, 17:35:53
ich habe so das gefühl, dass FHEM bald DOIF heisst. ;)
Wollen wir nicht hoffen ;)
So, ich habe meine Testphase abgeschlossen. Testversion ist im ersten Post angehängt. Doku fehlt noch, dafür habe ich alle wichtigen Neuerungen anhand von Beispielen im ersten Post dargestellt.
Gruß
Damian
Danke für die Erweiterungen.
Eine Frage: gibt es eine Möglichkeit, einen Befehlt z.B. 30 Sekunden nach dem FHEM-Start auszuführen?
Gruss
flurin
Zitat von: flurin am 30 März 2015, 21:31:00
Danke für die Erweiterungen.
Eine Frage: gibt es eine Möglichkeit, einen Befehlt z.B. 30 Sekunden nach dem FHEM-Start auszuführen?
Gruss
flurin
Hatten wir das nicht schon mal:
define di_init DOIF ([global:?INITIALIZED]) (set bla on)
attr di_init wait 30
attr di_init initialize initGruß
Damian
Zitat von: Damian am 30 März 2015, 21:41:57
Hatten wir das nicht schon mal:
define di_init DOIF ([global:?INITIALIZED]) (set bla on)
attr di_init wait 30
attr di_init initialize init
Gruß
Damian
OK, ich muss es übersehen haben.
@Damian
Nach einem ersten Versuch scheint es bei mir (mit der Version 2015-03-08) nicht zu funktionieren.
Gruss
flurin
Moin, Damian,
die Testversion läuft bei mir im Einsatzfall "alle 15 Minuten" ausführen sehr gut. Allerdings meldet Sie mir immer einen Error, was in Wirklichkeit der Rückgabewert einer eigenen Prozedur ist, die DOIF aufruft. Hier das Listings:
Internals:
DEF ([+900]) ({prg_MAX_Actuator()})
NAME DI_Heizanforder
STATE 31.03.2015 08:51:54
TYPE DOIF
Readings:
2015-03-31 08:36:54 Max_Ventil 65
2015-03-31 08:36:54 cmd_event timer_1
2015-03-31 08:36:54 cmd_nr 1
2015-03-31 08:36:54 error {prg_MAX_Actuator()}: 53
2015-03-31 08:36:54 state cmd_1
2015-03-31 08:36:54 timer_1_c1 31.03.2015 08:51:54
Condition:
0 DOIF_time_once($hash->{timer}{0},$wday,"")
Days:
Devices:
Do:
0 {prg_MAX_Actuator()}
Helper:
last_timer 1
sleeptimer -1
Internals:
Itimer:
Readings:
Realtime:
0 08:51:54
State:
Time:
0 +900
Timecond:
0 0
Timer:
0 0
Timerfunc:
Timers:
0 0
Attributes:
disable 0
do always
group Heizung
initialize initialized
room Heizung
stateFormat timer_1_c1
Für mich ist auch unverständlich, worauf die Condition beruht...
Das wichtigste zum Schluss: Es funktioniert bei mir als Ersatz des allereinfachsten aller AT, dem Wiederholungstimer...
Herzliche Grüße
Christian
Zitat von: cwagner am 31 März 2015, 08:53:54
Moin, Damian,
die Testversion läuft bei mir im Einsatzfall "alle 15 Minuten" ausführen sehr gut. Allerdings meldet Sie mir immer einen Error, was in Wirklichkeit der Rückgabewert einer eigenen Prozedur ist, die DOIF aufruft. Hier das Listings:
Internals:
DEF ([+900]) ({prg_MAX_Actuator()})
NAME DI_Heizanforder
STATE 31.03.2015 08:51:54
TYPE DOIF
Readings:
2015-03-31 08:36:54 Max_Ventil 65
2015-03-31 08:36:54 cmd_event timer_1
2015-03-31 08:36:54 cmd_nr 1
2015-03-31 08:36:54 error {prg_MAX_Actuator()}: 53
2015-03-31 08:36:54 state cmd_1
2015-03-31 08:36:54 timer_1_c1 31.03.2015 08:51:54
Condition:
0 DOIF_time_once($hash->{timer}{0},$wday,"")
Days:
Devices:
Do:
0 {prg_MAX_Actuator()}
Helper:
last_timer 1
sleeptimer -1
Internals:
Itimer:
Readings:
Realtime:
0 08:51:54
State:
Time:
0 +900
Timecond:
0 0
Timer:
0 0
Timerfunc:
Timers:
0 0
Attributes:
disable 0
do always
group Heizung
initialize initialized
room Heizung
stateFormat timer_1_c1
Für mich ist auch unverständlich, worauf die Condition beruht...
Das wichtigste zum Schluss: Es funktioniert bei mir als Ersatz des allereinfachsten aller AT, dem Wiederholungstimer...
Herzliche Grüße
Christian
Du musst am Ende deiner Perl-Funktion: return 0 oder return "" einbauen, dann kommt keine Fehlermeldung mehr.
In der Kondition werden alle eckigen Klammern untersucht und gegen Perl-Funktionen ersetzt. Außerdem erkennt mein Parser, ob es eine Zeitangabe ist oder ein Status, Reading, Internel. Bei Zeitangaben werden entsprechende Timer gesetzt.
Der Ausdruck [+900] ist eigentlich die kleinste Änderung und ging bisher auch schon über [+00:15]. Neu ist z. B. auch [+:15] hier wird zwar auch alle 15 Minuten getriggert allerdings ausgerichtet auf 15 Minutengrenzen, das wäre interessant für einen Gong.
Die neuen Zeitangaben in eckigen Klammern sind natürlich, wie bisher, mit anderen Ausrücken beliebig kombinierbar, z. B.
DOIF ([+900] and [Lampe] eq "on"...Das sollte aber klar sein.
Gruß
Damian
Zitat von: flurin am 30 März 2015, 22:43:36
@Damian
Nach einem ersten Versuch scheint es bei mir (mit der Version 2015-03-08) nicht zu funktionieren.
Gruss
flurin
Habe es in der Testversion im ersten Post gefixt. Nimm solange diese, bis ich sie einchecke.
Gruß
Damian
Zitat von: Damian am 31 März 2015, 16:37:26
Habe es in der Testversion im ersten Post gefixt. Nimm solange diese, bis ich sie einchecke.
Gruß
Damian
Testversion kopiert und FHEM-Restart ausgeführt. Leider geht es immer noch nicht.
Um "Verständnisprobleme" zu vermeiden, habe ich genau deine Definition mit einer kleinen Änderung übernommen:
define di_init DOIF ([global:?INITIALIZED]) ({Log(3,"DOIF:init")})
attr di_init wait 30
attr di_init initialize init
Gruss
flurin
Zitat von: flurin am 31 März 2015, 17:10:23
Testversion kopiert und FHEM-Restart ausgeführt. Leider geht es immer noch nicht.
Um "Verständnisprobleme" zu vermeiden, habe ich genau deine Definition mit einer kleinen Änderung übernommen:
define di_init DOIF ([global:?INITIALIZED]) ({Log(3,"DOIF:init")})
attr di_init wait 30
attr di_init initialize init
Gruss
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.
define di_init DOIF ([global:?INITIALIZED]) ((sleep 30;{Log(3,"DOIF:init")}))Gruß
Damian
Zitat von: Damian am 31 März 2015, 17:34:50
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.
define di_init DOIF ([global:?INITIALIZED]) ((sleep 30;{Log(3,"DOIF:init")}))
Gruß
Damian
OK, es geht auch bei mir. Hier eine praktische Anwendung:
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
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:
define n_sanctum_infrared_timer notify sanctum_infrared:on sleep 3600;;set sanctum_infrared off
Gruss
flurin
Ist es beabsichtigt, dass bei disabled DOIF der Timer weiter läuft?
Siehe Screenshot
Gruß
Christian
Zitat von: cwagner am 01 April 2015, 07:43:20
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
Zitat von: Damian am 31 März 2015, 10:06:16
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...
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:
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!
Zitat von: joshi04 am 03 April 2015, 13:40:07
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:
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
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!
Zitat von: joshi04 am 03 April 2015, 14:19:41
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:
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:5400Statt "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
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.
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
Zitat von: KernSani am 05 April 2015, 20:17:26
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
ok, man muss es ja auch nicht übertreiben, dachte nur ich übersehe etwas.
Danke,
Oli
Zitat von: KernSani am 05 April 2015, 21:47:53
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
Ich habe die neue Version eingecheckt. Die Doku wurde z. T. stark überarbeitet.
Gruß
Damian
Das ist ja mal der Hammer!
Vielen Dank für Deine Arbeit, die Du Dir da gemacht hast!
Hallo,
ich hab seit dem ich heute Morgen ein Update gemacht habe ein Problem. Ich vermute es ist ein BUG, da ich mehrere ähnliche DOIF's verwende, die auch keine Probleme bereiten. An dem Problem DOIF habe ich auch nichts verändert. Das Problem besteht darin, dass es nicht mehr auf CMD2 springt, durch anhängen eines DOELSE funktioniert es wieder. Habe mal ein list von beide Varianten gemacht.
list ohne DOELSE
Internals:
DEF ([Schaltsteckdose_1_SenPwr] < 10) (set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 '')
NAME ueberw_kuehltruhe
NR 192
NTFY_ORDER 50-ueberw_kuehltruhe
STATE Alarm
TYPE DOIF
Readings:
2015-04-06 19:42:38 cmd_event Schaltsteckdose_1_SenPwr
2015-04-06 19:42:38 cmd_nr 1
2015-04-06 19:58:21 e_Schaltsteckdose_1_SenPwr_STATE 113.78
2015-04-06 19:42:38 state Alarm
2015-04-06 19:45:19 wait_timer 06.04.2015 22:45:19 cmd_1 Schaltsteckdose_1_SenPwr
Condition:
0 InternalDoIf('Schaltsteckdose_1_SenPwr','STATE','') < 10
Devices:
0 Schaltsteckdose_1_SenPwr
all Schaltsteckdose_1_SenPwr
Do:
0 set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 ''
Helper:
last_timer 0
sleepdevice Schaltsteckdose_1_SenPwr
sleeptimer 0
Internals:
0 Schaltsteckdose_1_SenPwr:STATE
all Schaltsteckdose_1_SenPwr:STATE
Itimer:
Readings:
State:
Timerfunc:
Trigger:
Attributes:
cmdState Alarm|laeuft
do always
room __Befehle
wait 10800
die Bedingung ist nicht wahr, aber das DOIF bleibt bei cmd 1
nun das list mit DOELSE
Internals:
DEF ([Schaltsteckdose_1_SenPwr] < 10) (set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 '') DOELSE
NAME ueberw_kuehltruhe
NR 192
NTFY_ORDER 50-ueberw_kuehltruhe
STATE laeuft
TYPE DOIF
Readings:
2015-04-06 20:00:52 cmd_event Schaltsteckdose_1_SenPwr
2015-04-06 20:00:52 cmd_nr 2
2015-04-06 20:00:52 e_Schaltsteckdose_1_SenPwr_STATE 110.4
2015-04-06 20:00:52 state laeuft
Condition:
0 InternalDoIf('Schaltsteckdose_1_SenPwr','STATE','') < 10
Devices:
0 Schaltsteckdose_1_SenPwr
all Schaltsteckdose_1_SenPwr
Do:
0 set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 ''
1
Helper:
last_timer 0
sleeptimer -1
Internals:
0 Schaltsteckdose_1_SenPwr:STATE
all Schaltsteckdose_1_SenPwr:STATE
Itimer:
Readings:
State:
Timerfunc:
Trigger:
Attributes:
cmdState Alarm|laeuft
do always
room __Befehle
wait 10800
hier ist das DOIF auf cmd 2 gesprungen, so wie es mMn richtig ist.
Wie gesagt habe ich mehrere DOIF's die ähnliche Aufgaben erfüllen, fertig Meldung für Waschmaschine und Trockner, beide funktionieren auch ohne ein DOELSE.
Gruß
Ingo
Zitat von: automatisierer am 06 April 2015, 20:14:52
Hallo,
ich hab seit dem ich heute Morgen ein Update gemacht habe ein Problem. Ich vermute es ist ein BUG, da ich mehrere ähnliche DOIF's verwende, die auch keine Probleme bereiten. An dem Problem DOIF habe ich auch nichts verändert. Das Problem besteht darin, dass es nicht mehr auf CMD2 springt, durch anhängen eines DOELSE funktioniert es wieder. Habe mal ein list von beide Varianten gemacht.
list ohne DOELSE
Internals:
DEF ([Schaltsteckdose_1_SenPwr] < 10) (set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 '')
NAME ueberw_kuehltruhe
NR 192
NTFY_ORDER 50-ueberw_kuehltruhe
STATE Alarm
TYPE DOIF
Readings:
2015-04-06 19:42:38 cmd_event Schaltsteckdose_1_SenPwr
2015-04-06 19:42:38 cmd_nr 1
2015-04-06 19:58:21 e_Schaltsteckdose_1_SenPwr_STATE 113.78
2015-04-06 19:42:38 state Alarm
2015-04-06 19:45:19 wait_timer 06.04.2015 22:45:19 cmd_1 Schaltsteckdose_1_SenPwr
Condition:
0 InternalDoIf('Schaltsteckdose_1_SenPwr','STATE','') < 10
Devices:
0 Schaltsteckdose_1_SenPwr
all Schaltsteckdose_1_SenPwr
Do:
0 set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 ''
Helper:
last_timer 0
sleepdevice Schaltsteckdose_1_SenPwr
sleeptimer 0
Internals:
0 Schaltsteckdose_1_SenPwr:STATE
all Schaltsteckdose_1_SenPwr:STATE
Itimer:
Readings:
State:
Timerfunc:
Trigger:
Attributes:
cmdState Alarm|laeuft
do always
room __Befehle
wait 10800
die Bedingung ist nicht wahr, aber das DOIF bleibt bei cmd 1
nun das list mit DOELSE
Internals:
DEF ([Schaltsteckdose_1_SenPwr] < 10) (set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 '') DOELSE
NAME ueberw_kuehltruhe
NR 192
NTFY_ORDER 50-ueberw_kuehltruhe
STATE laeuft
TYPE DOIF
Readings:
2015-04-06 20:00:52 cmd_event Schaltsteckdose_1_SenPwr
2015-04-06 20:00:52 cmd_nr 2
2015-04-06 20:00:52 e_Schaltsteckdose_1_SenPwr_STATE 110.4
2015-04-06 20:00:52 state laeuft
Condition:
0 InternalDoIf('Schaltsteckdose_1_SenPwr','STATE','') < 10
Devices:
0 Schaltsteckdose_1_SenPwr
all Schaltsteckdose_1_SenPwr
Do:
0 set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 ''
1
Helper:
last_timer 0
sleeptimer -1
Internals:
0 Schaltsteckdose_1_SenPwr:STATE
all Schaltsteckdose_1_SenPwr:STATE
Itimer:
Readings:
State:
Timerfunc:
Trigger:
Attributes:
cmdState Alarm|laeuft
do always
room __Befehle
wait 10800
hier ist das DOIF auf cmd 2 gesprungen, so wie es mMn richtig ist.
Wie gesagt habe ich mehrere DOIF's die ähnliche Aufgaben erfüllen, fertig Meldung für Waschmaschine und Trockner, beide funktionieren auch ohne ein DOELSE.
Gruß
Ingo
ja, das habe ich wegen eines anderen Problems geändert, siehe hier:
http://forum.fhem.de/index.php/topic,30847.msg281484.html#msg281484
do always macht hier, so wie ich es gerade überblicke keinen Sinn. Lösche es, dann funktioniert es schon. Ansonsten hast du die von mir angedachte Lösung für "sinnvolle" do always Fälle ohne DOELSE mit der alleinigen DOELSE-Angabe schon selbst richtig erkannt.
Gruß
Damian
Ich habe ja meine DOIF-Anweisung für meine WandUhr abgeändert nach den neusten Anpassungen.
([Wanduhr_dummy:state] eq "on" and [:00]) ({WandUhr()})
DOELSEIF ([:15] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_15.mp3 -volume 83 −really−quiet &")})
DOELSEIF ([:30] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_30.mp3 -volume 83 −really−quiet &")})
DOELSEIF ([:45] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_45.mp3 -volume 83 −really−quiet &")})
Was mir nun aufgefallen ist, das mein FHEM nun immer ein save haben möchte. Könnte das mit der Umstellung zu tun haben?
Ich wüsste nämlich sonst nichts, was ich geändert hätte...
Zitat von: Toto1973 am 09 April 2015, 11:53:53
Ich habe ja meine DOIF-Anweisung für meine WandUhr abgeändert nach den neusten Anpassungen.
([Wanduhr_dummy:state] eq "on" and [:00]) ({WandUhr()})
DOELSEIF ([:15] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_15.mp3 -volume 83 −really−quiet &")})
DOELSEIF ([:30] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_30.mp3 -volume 83 −really−quiet &")})
DOELSEIF ([:45] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_45.mp3 -volume 83 −really−quiet &")})
Was mir nun aufgefallen ist, das mein FHEM nun immer ein save haben möchte. Könnte das mit der Umstellung zu tun haben?
Ich wüsste nämlich sonst nichts, was ich geändert hätte...
Dann müsste sich hier etwas an der Konfiguration ändert - das ist hier nicht der Fall. Ich habe den Befehl bei mir definiert. WandUhr und mplayer führt zwar zu einer Fehlermeldung, weil es die bei mir nicht gibt. Bei Save Config wird das Fragezeichen aber nicht aktiv.
Gruß
Damian
ZitatWas mir nun aufgefallen ist, das mein FHEM nun immer ein save haben möchte. Könnte das mit der Umstellung zu tun haben?
Ich wüsste nämlich sonst nichts, was ich geändert hätte...
Bei mir kommt das z.B. durch die Einbindung des calendar bzw. calview , hier werden innerhalb der readingsgroup über at
die Daten aktualisiert !
Danke für den Hinweis!
Da muss ich mal genauer nachsehen, wo das her kommt!
Können diese neuen Zeit-Features eigentlich auch dazu genutzt werden, um verschiedene Zeitraster am Tag zu benutzen?
Ich starte meine Zirkulationspumpe folgendermaßen:
([+00:10]) (set powerMeter1_switch on-for-timer 120)
Ich möchte diesen Abstand aber in der Nacht erhöhen. Also muss ich Zeitraum und Zeitraster in der Bedingung kombinieren. Geht das?
Zitat von: Funk.Odyssey am 12 April 2015, 20:54:22
Können diese neuen Zeit-Features eigentlich auch dazu genutzt werden, um verschiedene Zeitraster am Tag zu benutzen?
Ich starte meine Zirkulationspumpe folgendermaßen:
([+00:10]) (set powerMeter1_switch on-for-timer 120)
Ich möchte diesen Abstand aber in der Nacht erhöhen. Also muss ich Zeitraum und Zeitraster in der Bedingung kombinieren. Geht das?
Schon etwas ausprobiert?
Bsp:
set Zeit 00:15
([+[Zeit]])(...)
oder
set Zeit 900
([+[Zeit]])(...)
oder
set Zeit +00:15
([[Zeit]]) (...)
oder ausgerichtet
set Zeit +:15
([[Zeit]]) (...)
Es gibt noch mehr Möglichkeiten mit runden Klammern (siehe Berechnung von Zeit in der Commandref), aber das sollte erst mal reichen.
such dir also etwas aus ;)
Edit: Dummy Zeit kannst du natürlich mit einem separaten DOIF zeitgesteuert setzen.
Gruß
Damian
Ich habe es quick&dirty folgendermaßen ausprobiert:
(
[22:00-06:00] and [+00:30]
)
(set powerMeter1_switch on-for-timer 150)
DOELSE
(set powerMeter1_switch on)
Muss noch schön gemacht werden. Aber es scheint zu funktionieren.
Zitat von: Toto1973 am 09 April 2015, 11:53:53
Ich habe ja meine DOIF-Anweisung für meine WandUhr abgeändert nach den neusten Anpassungen.
([Wanduhr_dummy:state] eq "on" and [:00]) ({WandUhr()})
DOELSEIF ([:15] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_15.mp3 -volume 83 −really−quiet &")})
DOELSEIF ([:30] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_30.mp3 -volume 83 −really−quiet &")})
DOELSEIF ([:45] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_45.mp3 -volume 83 −really−quiet &")})
Was mir nun aufgefallen ist, das mein FHEM nun immer ein save haben möchte. Könnte das mit der Umstellung zu tun haben?
Ich wüsste nämlich sonst nichts, was ich geändert hätte...
Deine WandUhr lässt mich nicht in Ruhe schlafen :)
ich hab's bei mir so vereinfacht:
define di_wall_clock DOIF ([+:15]) ({system("mplayer /opt/fhem/Sound/BigBen_".$min.".mp3 -volume 83 −really−quiet &")})
attr di_wall_clock do always
Gruss
flurin
Ich muss hier auch mal wieder was nachfragen.
Seit Anfang an mache ich mich mit dieser "Schaltung" hier rum:
([09:01-20:00] and [sz_Waesche_trocknen] eq "on" and [?Jahreszeit] eq "Winter") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([Jahreszeit] eq "Sommer") (set sz_Heizung desiredTemperature off)
DOELSEIF ([03:30-05:00|8] and [geofancy:currLoc_Toto] eq "Home" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Frueh") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([07:45-09:00|8] and [geofancy:currLoc_Toto] eq "Home" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Mittel") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([09:01-11:00] and [?sz_Waesche_trocknen] eq "off" and [?Jahreszeit] eq "Winter" and [geofancy:currLoc_Toto] eq "Home") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([11:01-18:00] and [?sz_Waesche_trocknen] eq "off" and [?Technoclub] eq "nein" and [?Jahreszeit] eq "Winter" and [geofancy:currLoc_Toto] eq "Home") (set sz_Heizung desiredTemperature 20)
DOELSEIF ([14:00-18:00|7] and [?sz_Waesche_trocknen] eq "off" and [Technoclub] eq "ja" and [?Jahreszeit] eq "Winter" and [geofancy:currLoc_Toto] eq "Home") (set sz_Heizung desiredTemperature 20)
DOELSE (set sz_Heizung desiredTemperature 17)
Es soll also zu verschiedenen Zeiten ein Heinzkörper gesteuert werden. Dies geschieht abhängig von verschiedene Faktoren (Dummys). Soweit funktioniert das auch im Teil ganz gut.
Allerdings springt mir der DOIF immer wieder in die DOELSE Bedienung, obwohl andere Bedienungen passen würde.
Also immer dann, wenn eine neue Zeit triggert, funktioniert es nicht mehr so, wie eigentlich gewollt.
Zu meinem Verständnis:
Ist es so, das DOIF zu erst die erste Bedingung abfragt (hier also die erste Zeile) und wenn die zutrifft, dann fragt es den Rest nicht mehr ab?
Weil ich vermute, das genau das nicht passiert!
Sprich, er fragt immer alles ab!
Ist das so richtig und wenn ja, kann man das nicht ändern?
Ergänzung:
Ich stelle mir das so vor:
Bedingung 1 wird durch die Uhrzeit und den Wäsche_trocknen Dummy wahr, dann ruht DOIF bis entweder die Endzeit erreicht ist (im Beispiel 20 Uhr) oder sich der Zustand des Wäsche_trocknen Dummy ändert.
Alle anderen Timer würde quasi ignoriert werden.
Das ganze könnte ja durch ein Attribut, das man setzen kann, aktiviert werden.
Das würde solche komplexen Steuerungen etwas übersichtlicher machen.
Zitat von: Toto1973 am 23 April 2015, 11:55:17
Ich muss hier auch mal wieder was nachfragen.
Seit Anfang an mache ich mich mit dieser "Schaltung" hier rum:
([09:01-20:00] and [sz_Waesche_trocknen] eq "on" and [?Jahreszeit] eq "Winter") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([Jahreszeit] eq "Sommer") (set sz_Heizung desiredTemperature off)
DOELSEIF ([03:30-05:00|8] and [geofancy:currLoc_Toto] eq "Home" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Frueh") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([07:45-09:00|8] and [geofancy:currLoc_Toto] eq "Home" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Mittel") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([09:01-11:00] and [?sz_Waesche_trocknen] eq "off" and [?Jahreszeit] eq "Winter" and [geofancy:currLoc_Toto] eq "Home") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([11:01-18:00] and [?sz_Waesche_trocknen] eq "off" and [?Technoclub] eq "nein" and [?Jahreszeit] eq "Winter" and [geofancy:currLoc_Toto] eq "Home") (set sz_Heizung desiredTemperature 20)
DOELSEIF ([14:00-18:00|7] and [?sz_Waesche_trocknen] eq "off" and [Technoclub] eq "ja" and [?Jahreszeit] eq "Winter" and [geofancy:currLoc_Toto] eq "Home") (set sz_Heizung desiredTemperature 20)
DOELSE (set sz_Heizung desiredTemperature 17)
Es soll also zu verschiedenen Zeiten ein Heinzkörper gesteuert werden. Dies geschieht abhängig von verschiedene Faktoren (Dummys). Soweit funktioniert das auch im Teil ganz gut.
Allerdings springt mir der DOIF immer wieder in die DOELSE Bedienung, obwohl andere Bedienungen passen würde.
Also immer dann, wenn eine neue Zeit triggert, funktioniert es nicht mehr so, wie eigentlich gewollt.
Zu meinem Verständnis:
Ist es so, das DOIF zu erst die erste Bedingung abfragt (hier also die erste Zeile) und wenn die zutrifft, dann fragt es den Rest nicht mehr ab?
Weil ich vermute, das genau das nicht passiert!
Sprich, er fragt immer alles ab!
Ist das so richtig und wenn ja, kann man das nicht ändern?
Zitat aus der Commandref:
ZitatDie Angaben werden immer von links nach rechts abgearbeitet. Es wird immer nur ein Kommando ausgeführt, und zwar das erste, für das die dazugehörige Bedingung in der abgearbeiteten Reihenfolge wahr ist. Hinzu kommt, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event auch das Device beinhalten.
Das gilt insb. auch für Zeittrigger, wenn also z. B. um 03:30 die dritte Bedingung getriggert wird, wird auch nur diese zu diesem Zeitpunkt geprüft und wenn sie nicht stimmt, dann wird der DOELSE-Fall ausgeführt.
Ein Problem kann es bei 09:01 Uhr geben, denn das Modul wird um diese Zeit zweimal getriggert, dabei ist die zeitliche Abfolge der Überprüfung nicht sichergestellt. Es kann also sein, dass zuerst die erste Bedingung geprüft wird und dann die fünfte, es kann aber auch sein dass zuerst die fünfte geprüft wird und dann erst die erste.
Wenn man sicherstellen will, dass zuerst die erste Bedingung geprüft wird und dann die fünfte, dann sollte man bei der fünften statt 09:01... einen etwas späteren Zeitpunkt angeben z. B. 09:01:01....
Zukünftig wird die Reihenfolge der Abarbeitung bei
gleicher Zeit sichergestellt werden (steht schon auf der todo-Liste).
Gruß
Damian
Das Problem ist aber noch die Zeitspanne oder?
Wenn eine Bedinung von 9 bis 11 Uhr geht, eine andere Bedingung von 10 bis 12 Uhr, dann wird um 10 Uhr geprüft und wenn die Bedinung nicht wahr ist, fällt DOIF auf die DOELSE Bedinung, richtig?
Logisch wäre ja dann aber, das Bedingung 1 weiter Bestand hätte, bis 11 Uhr.
Zitat von: Toto1973 am 23 April 2015, 13:00:59
Das Problem ist aber noch die Zeitspanne oder?
Wenn eine Bedinung von 9 bis 11 Uhr geht, eine andere Bedingung von 10 bis 12 Uhr, dann wird um 10 Uhr geprüft und wenn die Bedinung nicht wahr ist, fällt DOIF auf die DOELSE Bedinung, richtig?
Logisch wäre ja dann aber, das Bedingung 1 weiter Bestand hätte, bis 11 Uhr.
ja, da könnte man überlegen, ob man Attribut-gesteuert bei irgendeinem Zeittrigger die Überprüfung aller Bedingungen vornimmt - ich kann aber z. Zt. die Konsequenzen einer solchen Vorgehensweise noch nicht absehen.
Es ist immer kritisch mehrere DOELSIF-Fälle mit Zeitintervallen und einem DOELSE-Fall anzugeben. Weil man höllisch auf Zeitüberschneidungen achten muss und der DOELSE-Fall öfters zum Zuge kommt als man denkt. In solchen Fällen würde ich ohne Intervalle arbeiten und stattdessen nur mit Zeitpunkten arbeiten, denn diese sind wesentlich unkritischer zu handhaben, weil sie nur zum Triggerzeitpunkt wahr sind und sonst nicht - da hat man weniger Probleme mit irgendwelchen Überschneidungen bzw. Abhängigkeiten.
Bei dir würde sich damit die Anzahl der Fälle auf drei reduzieren temp 22, temp 20 und temp 17. In der entsprechenden Bedingung würde ich nur Zeitpunkte angeben, ab wann die Temperatur gelten soll und keinen DOELSE-Fall angeben.
Gruß
Damian
Vielen Dank für die Antwort. Ich werde das Ganze mal umbauen
Hallo Damian,
in Sachen Zeit-Features hätte ich noch eine Idee:
Ich möchte in verschiedenen DOIFs die Abfrage einbauen, ob seit dem Zeitpunkt der letzten Aktualisierung eines Readings bis jetzt eine Zeit von mehr oder weniger als XX Sekunden vergangen ist. Zur Zeit kann ich das m.E. nur durch eine Perl-Funktion realisieren, was ich auch tue.
Toll wäre aber, wenn das direkt in der DOIF-Definition mit eingebaut werden könnte nach folgendem Beispiel (hier steht die # für das Alter des Zeitstempels in Sekunden vom aktuellen Zeitpunkt - hier dann inkl. Trigger-Auslösung):
define Aktion DOIF ([IrgendeinEvent] and [#Mein_Device] > 30) (set Lampe on)
bzw. ohne Triggerauslösung
define Aktion DOIF ([IrgendeinEvent] and [?#Mein_Device] > 30) (set Lampe on)
Damit könnte man bei alleinigem Definitionsmerkmal insgesamt auch wunderbar Aktionen anstossen, bei denen bspw. die letzte Aktualisierung eines Readings schon XX Zeiteinheiten her ist.
Zitat von: Ralli am 24 April 2015, 08:20:14
Hallo Damian,
in Sachen Zeit-Features hätte ich noch eine Idee:
Ich möchte in verschiedenen DOIFs die Abfrage einbauen, ob seit dem Zeitpunkt der letzten Aktualisierung eines Readings bis jetzt eine Zeit von mehr oder weniger als XX Sekunden vergangen ist. Zur Zeit kann ich das m.E. nur durch eine Perl-Funktion realisieren, was ich auch tue.
Toll wäre aber, wenn das direkt in der DOIF-Definition mit eingebaut werden könnte nach folgendem Beispiel (hier steht die # für das Alter des Zeitstempels in Sekunden vom aktuellen Zeitpunkt - hier dann inkl. Trigger-Auslösung):
define Aktion DOIF ([IrgendeinEvent] and [#Mein_Device] > 30) (set Lampe on)
bzw. ohne Triggerauslösung
define Aktion DOIF ([IrgendeinEvent] and [?#Mein_Device] > 30) (set Lampe on)
Damit könnte man bei alleinigem Definitionsmerkmal insgesamt auch wunderbar Aktionen anstossen, bei denen bspw. die letzte Aktualisierung eines Readings schon XX Zeiteinheiten her ist.
So etwas gibt es schon, siehe Commandref:
define Aktion DOIF ([IrgendeinEvent] and [?Mein_Device:reading:sec] > 30) (set Lampe on)
Gruß
Damian
:o Uff. Danke.
DOIF ist ja inzwischen so Umfangreich geworden, das man den Überblick verliert. Außerdem macht es viele andere Module inzwischen überflüssig!
Bei meinem Problem ist wohl DOIF nicht schuld. Ich vermute, das Geofancy da der Auslöser ist. Heute ist um 9:22 Uhr der DOELSE Fall eingetreten. Und da triggert keine Zeit.
Nach dem ich den Status von Geofancy nochmal auf home gesetzt habe, hat auch die passende Bedingung wieder geschallten.
Also werde ich mal da nach forschen...
Das Problem mit der zeit bleibt allerdings doch. Ich muss quasi alle Zeitabschnitte, die sich irgendwie überschneiden könnten, umgehen. Das wird ein Spaß, das zusammen zu bauen :-P
So sieht das dann aus, nach der Umstellung. Hier das Beispiel für das Thermostat im Bad.
([03:30:01|8] or [07:45:01|8] or [09:00:01|7] or [11:00:01] or [05:00:01|8] or [22:00:01] and [Jahreszeit] eq "Sommer" and [?Anwesend] eq "on" or [?Anwesend] eq "off") (set ba_Heizung desiredTemperature off)
DOELSEIF ([03:30|8] and [Anwesend] eq "on" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Frueh") (set ba_Heizung desiredTemperature 22)
DOELSEIF ([07:45|8] and [Anwesend] eq "on" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Mittel") (set ba_Heizung desiredTemperature 22)
DOELSEIF ([09:00|7] and [Anwesend] eq "on" and [?Jahreszeit] eq "Winter") (set ba_Heizung desiredTemperature 22)
DOELSEIF ([11:00] and [Anwesend] eq "on" and [?Jahreszeit] eq "Winter") (set ba_Heizung desiredTemperature 20)
DOELSEIF ([05:00|8] or [22:00] and [Anwesend] eq "off") (set ba_Heizung desiredTemperature 18)
So müsste ich alle Bedingungen abgedeckt haben und auch die Uhrzeiten sollten abgefangen werden...
Ergänzung:
Bei der ersten Bedingung habe ich mal wieder zu weit gedacht!
Da ja nur dann was geschalten wird, wenn eine Bedingung wahr wird, kann ich die ganzen Zeitangaben sowie die Abfrage für Anwesend weglassen oder?
Für die Erfassung, wenn Anwesend von Off auf on springt, brauche ich dann eine separate DOIF, die je nach Zeitfenster, den Thermostat steuert.
Zitat von: Toto1973 am 24 April 2015, 12:13:46
So sieht das dann aus, nach der Umstellung. Hier das Beispiel für das Thermostat im Bad.
([03:30:01|8] or [07:45:01|8] or [09:00:01|7] or [11:00:01] or [05:00:01|8] or [22:00:01] and [Jahreszeit] eq "Sommer" and [?Anwesend] eq "on" or [?Anwesend] eq "off") (set ba_Heizung desiredTemperature off)
DOELSEIF ([03:30|8] and [Anwesend] eq "on" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Frueh") (set ba_Heizung desiredTemperature 22)
DOELSEIF ([07:45|8] and [Anwesend] eq "on" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Mittel") (set ba_Heizung desiredTemperature 22)
DOELSEIF ([09:00|7] and [Anwesend] eq "on" and [?Jahreszeit] eq "Winter") (set ba_Heizung desiredTemperature 22)
DOELSEIF ([11:00] and [Anwesend] eq "on" and [?Jahreszeit] eq "Winter") (set ba_Heizung desiredTemperature 20)
DOELSEIF ([05:00|8] or [22:00] and [Anwesend] eq "off") (set ba_Heizung desiredTemperature 18)
So müsste ich alle Bedingungen abgedeckt haben und auch die Uhrzeiten sollten abgefangen werden...
Ich würde dennoch Fälle mit gleicher Temperatur jeweils zu einem Zustand zusammenfassen, damit ggf. nicht unnötig geschaltet wird:
([03:30:01|8] or [07:45:01|8] or [09:00:01|7] or [11:00:01] or [05:00:01|8] or [22:00:01] and [Jahreszeit] eq "Sommer" and [?Anwesend] eq "on" or [?Anwesend] eq "off")
(set ba_Heizung desiredTemperature off)
DOELSEIF (([03:30|8] and [Anwesend] eq "on" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Frueh") or
([07:45|8] and [Anwesend] eq "on" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Mittel") or
([09:00|7] and [Anwesend] eq "on" and [?Jahreszeit] eq "Winter")
(set ba_Heizung desiredTemperature 22)
DOELSEIF ([11:00] and [Anwesend] eq "on" and [?Jahreszeit] eq "Winter")
(set ba_Heizung desiredTemperature 20)
DOELSEIF ([05:00|8] or [22:00] and [Anwesend] eq "off")
(set ba_Heizung desiredTemperature 18)Gruß
Damian
Kurze Rückmeldung:
Nachdem ich jetzt alles so umgebaut habe, wie vorgeschlagen, funktioniert meine Heizungssteuerung endlich wie gewollt. Vielen Dank!
Manchmal kommt man selbst nicht auf die einfachsten Dinge ;-)
Guten Morgen,
ist evtl. auch eine Erweiterung geplant, bei der man wie zB. die Wochentage, auch Monate setzen kann ? [06:00-12:00|123|M04M5M6M11] Also Mo+Di+Mi in April|Mai|Juni|November
Fänd ich gut bei Bewässerungsteuerung, Heizungsteuerung etc.....
LG
Zitat von: Bartimaus am 04 Mai 2015, 09:19:54
Guten Morgen,
ist evtl. auch eine Erweiterung geplant, bei der man wie zB. die Wochentage, auch Monate setzen kann ? [06:00-12:00|123|M04M5M6M11] Also Mo+Di+Mi in April|Mai|Juni|November
Fänd ich gut bei Bewässerungsteuerung, Heizungsteuerung etc.....
LG
so nicht, aber du kannst heute schon angeben:
([06:00-12:00|123] and ($month>=4 and $month<=6)) (...
Gruß
Damian
So nutze ich es derzeit ;)
Aber je schlanker desto besser ;D
Zitat von: Bartimaus am 04 Mai 2015, 12:24:58
So nutze ich es derzeit ;)
Aber je schlanker desto besser ;D
ja, mal schauen, was sonst noch auf der todo-Liste steht, wenn ich wieder Zeit habe :)
Gruß
Damian
Zitat von: Damian am 29 März 2015, 22:16:05
Ich habe heute das schlechte Wetter genutzt und neue Zeit-Features ins Modul eingebaut.
2. Rechnen mit Zeit: Beliebige Perlausdrücke in Kombination mit Zeitangaben im üblichen Format: HH:MM, Readings oder Stati sowie Perlfunktionen.
Beispiele:
relative Zeitangaben in Sekunden: Trigger alle 100 Sekunden
DOIF ([+100]) (set bla on)
Gruß
Damian
Hallo.
Habe da ein Problem mit genau diesem Beispiel..
Ich möchte alle 60sec. einen Dummy setzen, aber das klappt nur nach der ersten Minute, danach wird nichts mehr aktualisiert.
([+60]) ({ my $sld = ReadingsVal("SDM220M","Power__W",0);; fhem("set Xtender_Loader $sld ");;})
bei den readings steht folgendes
cmd_event timer_1 2015-05-13 19:12:59
cmd_nr 1 2015-05-13 19:12:59
state cmd_1 2015-05-13 19:12:59
timer_1_c1 13.05.2015 19:24:59 2015-05-13 19:23:59
Zitat von: satprofi am 13 Mai 2015, 19:28:07
Hallo.
Habe da ein Problem mit genau diesem Beispiel..
Ich möchte alle 60sec. einen Dummy setzen, aber das klappt nur nach der ersten Minute, danach wird nichts mehr aktualisiert.
([+60]) (set Xtender_Loader [SDM220M:Power__W:d])
bei den readings steht folgendes
cmd_event timer_1 2015-05-13 19:12:59
cmd_nr 1 2015-05-13 19:12:59
state cmd_1 2015-05-13 19:12:59
timer_1_c1 13.05.2015 19:24:59 2015-05-13 19:23:59
Ist do always gesetzt?
attr .... do always
Danke, das wars!
Wusste ich nicht.
Wozu hat sich Damian die Mühe mit einer deutschen commandref gemacht wenn sie sowieso nicht gelesen wird ???
Wozu gibt es im Forum unzählige Beiträge wenn sie auch nicht gelesen werden ???
Zitat von: satprofi am 13 Mai 2015, 19:57:06
Danke, das wars!
Wusste ich nicht.
Klar, die logische Entschuldigung für ... schlechte Doku nehm ich mal an.
Aber ok, die Hilfe im Forum nimmt einem das suchen ab und kostet nichts.
Ist nur fraglich wie lange sich Leute noch einbringen wenn es doch einfacher ist im Forum zu posten.
Habe command ref gelesen. Leider sund da aber die neuen zeitfunktionen nicht drinn
Sent from my OPO
Wetten das do always drinnen steht.
Auch wette ich das do always bereits zigmal hier beschrieben wurde.
ZitatHabe command ref gelesen. Leider sund da aber die neuen zeitfunktionen nicht drinn
Aber die Attribute sind beschrieben - in der commandref und hier im Forum.
Und an den Attributen hat sich nichts geändert - weder hier im Forum noch in der commandref.
Ok. Bei do always war ich der meinung das dies nur dann aktiv sein soll wenn andere devices zwischenfunken.
Sent from my OPO
Dann weicht deine Meinung von der Programmierung des DOIF sowie von der Erklärung in der commandref und auch den Erklärungen im Foum ab und ist falsch.
Wird so sein
Sent from my OPO
Zitat von: satprofi am 14 Mai 2015, 10:47:40
Wird so sein
Sent from my OPO
Mit "do always" hatte ich am Anfang trotz hervorragender Dokumentation meine Mühe. Eigentlich lernt man den richtigen Gebrauch nur mit der praktischen Anwendung. Selbst Damian muss immer wieder darauf hinweisen.
Zudem haben neue Forumsbeiträge IMHO einen positiven Nebeneffekt. Sie sind aktuell und widerspiegeln den neusten Stand der Module. Alte Beiträge sind oft nicht mehr gültig oder komplizierter.
Gruss
flurin
Hi, ich bin neu hier und habe inzwischen alles auf DOIF umgestellt. Vielen Dank für die tolle Arbeit, das ist für mich vieeel einfacher zu nutzen als AT und NOTIFY :)
Eine Frage habe ich:
Ich würde gerne Rolladen um einen zufälligen Zeitraum (z.B. 0-10 Minuten) verzögert fahren lassen und habe das bisher erfolglos mit der wait Funktion probiert:
(([wetter.sonnenstand.dg_sued] eq "ein") or ([zeit.schlafen] eq "ein")) (bla bla Rolladen fahren runter)
wait int(rand(600))
PERL WARNING: Argument "int(rand(30))" isn't numeric in addition (+) at /usr/local/FHEM/share/fhem/FHEM/98_DOIF.pm line 1018.
Ist es mit wait möglich, eine zufällige Anzahl von Sekunden mit der Ausführung zu warten?
Grüße,
Alex
Zitat von: All-Ex am 14 Mai 2015, 20:18:26
Hi, ich bin neu hier und habe inzwischen alles auf DOIF umgestellt. Vielen Dank für die tolle Arbeit, das ist für mich vieeel einfacher zu nutzen als AT und NOTIFY :)
Eine Frage habe ich:
Ich würde gerne Rolladen um einen zufälligen Zeitraum (z.B. 0-10 Minuten) verzögert fahren lassen und habe das bisher erfolglos mit der wait Funktion probiert:
(([wetter.sonnenstand.dg_sued] eq "ein") or ([zeit.schlafen] eq "ein")) (bla bla Rolladen fahren runter)
wait int(rand(600))
PERL WARNING: Argument "int(rand(30))" isn't numeric in addition (+) at /usr/local/FHEM/share/fhem/FHEM/98_DOIF.pm line 1018.
Ist es mit wait möglich, eine zufällige Anzahl von Sekunden mit der Ausführung zu warten?
Grüße,
Alex
Bei wait als Attribut sind z. Zt. nur feste Sekundenangaben möglich.
Du könntest es aber mit einem konventionellem sleep machen, z. B.
(([wetter.sonnenstand.dg_sued] eq "ein") or ([zeit.schlafen] eq "ein")) (sleep {(int(rand(30)))};bla bla Rolladen fahren runter)mit einem Semikolon in DEF eingeben, in der Kommandozeile, mit zwei. Bitte beachten: eine solche sleep-Angabe funktioniert nur in DOIF, beim notify müsste man über Perl gehen.
Variable Angaben beim wait-Attribut werde ich mal auf die todo-Liste setzen.
Gruß
Damian
Danke für die schnelle Antwort, funktioniert! :)
Servus zusammen!
Ich stricke gerade an einem DOIF für meine Waschmaschine. Dabei soll ein Dummy "Waschmaschine" wenn die Maschine fertig ist, den Status für 90 Minuten auf "Waschmaschine finished" setzen. Danach soll der Dummy auf den Status "Waschmaschine standby" gesetzt werden (immer vorausgesetzt, dass die Maschine in dieser Zeit nicht wieder in Betrieb geht). So recht hinhauen mag es aber noch nicht. Kann/ mag mir jemand auf die Sprünge helfen?
([WM_SenPwr] > 5) (set Waschmaschine running) DOELSEIF ([WM_SenPwr]< 5) (set Waschmaschine finished) DOELSEIF ([WM_SenPwr] = 0) (set Waschmaschine off) DOELSE (Waschmaschine standby)
...
attr <name> wait 300:5400
attr <name> wait 300:5400:0:0
Zitat von: tomster am 15 Mai 2015, 12:04:19
([WM_SenPwr] > 5) (set Waschmaschine running) DOELSEIF ([WM_SenPwr]< 5) (set Waschmaschine finished) DOELSEIF ([WM_SenPwr] = 0) (set Waschmaschine off) DOELSE (Waschmaschine standby)
Das DOIF wird so nix. Die dritte Alternative kommt nie zum Tragen, da vorher schon < 5 zuschlägt. Und die letzte Alternative wird auch nie zutreffen.
Zitat von: Ralli am 15 Mai 2015, 12:39:28
Das DOIF wird so nix. Die dritte Alternative kommt nie zum Tragen, da vorher schon < 5 zuschlägt. Und die letzte Alternative wird auch nie zutreffen.
OOPS, da hat er Recht, der Ralli...
versuchs mal so
([WM_SenPwr]< 5) (set Waschmaschine finished)
DOELSEIF ([WM_SenPwr] < 1) (set Waschmaschine off)
DOELSE (set Waschmaschine running)
Das wird auch nix. :D
Zitat von: Ralli am 15 Mai 2015, 14:42:14
Das wird auch nix. :D
glaub ich nicht.
das funktioniert auch
([Pac] > 2500 and [08:00-22:00]) (set LED_01 led green)
DOELSEIF ([Pac] > 1000 and [08:00-22:00]) ( set LED_01 led orange)
DOELSEIF ([Pac] < 1000 and [08:00-22:00]) (set LED_01 led red)
So könnte es klappen:
define di_WM DOIF ([WM_SenPwr] == 0)
(setreading Waschmaschine state off)
DOELSEIF ([WM_SenPwr] > 5)
(setreading Waschmaschine state running)
DOELSEIF ([WM_SenPwr] < 5 and [Waschmaschine] eq "running")
(setreading Waschmaschine state finished)
DOELSEIF ([Waschmaschine] eq "finished")
(setreading Waschmaschine state standby)
attr di_WM wait 0:0:0:5400
Flurin, das funktioniert genauso wie ich es mir vorgestellt habe. Vielen Dank!
Hab das wait noch nach 0:0:300:5400 angepasst, damit das finished auch wirklich finished anzeigt.
Zitat von: tomster am 15 Mai 2015, 16:16:50
Flurin, das funktioniert genauso wie ich es mir vorgestellt habe. Vielen Dank!
Hab das wait noch nach 0:0:300:5400 angepasst, damit das finished auch wirklich finished anzeigt.
Okey, mit Event monitor würde ich mal untersuchen, wie oft "Waschmaschine" gesetzt wird.
Vermutlich wird bei jeder WM_SenPwr-Änderung getriggert.
Wie ist der Bereich von WM_SenPwr? 0 bis xxx
Zitat von: flurin am 15 Mai 2015, 16:31:25
Okey, mit Event monitor würde ich mal untersuchen, wie oft "Waschmaschine" gesetzt wird.
Vermutlich wird bei jeder WM_SenPwr-Änderung getriggert.
Wie ist der Bereich von WM_SenPwr? 0 bis xxx
Ja, es wird bei jeder Änderung getriggert. Im "Leerlauf" hab ich fast immer Werte zwischen 3.87 und 3.89. Ein event-on-change-reading mit entsprechendem Bereich dürfte die Trigger deutlich reduzieren. Probier ich mal.
Die Werte gehen laut offiziellen Angaben von eq-3 von 0-3680 Watt. Ich hab aber auch schon Werte um die 4500 Watt gesehen...
Zitat von: tomster am 15 Mai 2015, 16:39:43
Ja, es wird bei jeder Änderung getriggert. Im "Leerlauf" hab ich fast immer Werte zwischen 3.87 und 3.89. Ein event-on-change-reading mit entsprechendem Bereich dürfte die Trigger deutlich reduzieren. Probier ich mal.
Die Werte gehen laut offiziellen Angaben von eq-3 von 0-3680 Watt. Ich hab aber auch schon Werte um die 4500 Watt gesehen...
... zusätzlich könnte man das DOIF optimieren:
define di_WM DOIF ([WM_SenPwr] == 0 and [?Waschmaschine] ne "off")
(setreading Waschmaschine state off)
DOELSEIF ([WM_SenPwr] > 5 and [?Waschmaschine] ne "running")
(setreading Waschmaschine state running)
DOELSEIF ([WM_SenPwr] < 5 and [?Waschmaschine] eq "running")
(setreading Waschmaschine state finished)
DOELSEIF ([Waschmaschine] eq "finished")
(setreading Waschmaschine state standby)
attr di_WM wait 0:0:300:5400
Mal was anderes. Ich habe einen 2er-Taster, auf den ein DOIF reagiert. Und zwar immer gleich, mit einem set blabla toggle.
Das DOIF habe ich mit do always definiert. Klappt auch alles einwandfrei. Nun meine Verständnisfrage.
Angenommen, es wird jetzt (aus Versehen) ein Doppeltaster gedrückt, wie kann ich das verhindern? Ich habe es mit
cmdpause 3
repeatsame 1
do resetwait (oder always)
versucht, das funktioniert nicht - hier wird immer nur ein einziges mal der Toggle ausgeführt (denn der State ändert sich ja nicht). Wo ist mein Denkfehler?
Zitat von: flurin am 15 Mai 2015, 16:31:25
Okey, mit Event monitor würde ich mal untersuchen, wie oft "Waschmaschine" gesetzt wird.
Vermutlich wird bei jeder WM_SenPwr-Änderung getriggert.
Das DOIF ja, aber solange sich der State des DOIFs nicht ändert, (also auch wenn seine Bedingung immer und immer wieder zutrifft) wird sein Ausführungsteil auch nicht erneut ausgeführt. Außer es wäre "do always" gesetzt, was hier aber gerade keinen Sinn macht.
Im übrigen meine ich mich zu erinnern, dass das DOIF den State einnimmt, der nach den Bedingungszweigen als erstes zutrifft, alle anderen werden ignoriert. Wenn man die Bedingung nach "Leistung = 0" also vor der Abfrage "Leistung <5" einträgt, sollte es auch klappen.
Zitat von: Ralli am 15 Mai 2015, 19:39:36
cmdpause 3
repeatsame 1
do resetwait (oder always)
... funktioniert nicht - hier wird immer nur ein einziges mal der Toggle ausgeführt Wo ist mein Denkfehler?
Mein Denkfehler (oder auch nicht) wäre "cmdpause 3" plus "do always", mehr nicht. cmdpause verzögert im Gegensatz zu wait nicht die Ausführung, sondern unterdrückt erneute Ausführungen für die Wartezeit.
repeatsame 1 hingegen sorgt dann dafür, dass es genau nur einmal funktioniert.
Danke, Pfriemler.
Und ich dachte, repeatsame 1 würde bedeuten, dass innerhalb der mit cmdpause 3 eingestellten Wartezeit das Kommando nur einmal in drei Sekunden ausgeführt wird und danach der Zähler wieder zurückgesetzt wird.
Ich probiere :).
Bezüglich Deiner anderen Antwort: So sollte es sein. Interessanterweise habe ich mit folgendem DOIF aber eine andere Erfahrung gemacht:
([05:00|8] and [?FL_Rollo] eq "off") (set FL_Treppenlicht 30) DOELSEIF ([06:00|7] and [?GEN_Aussensensor:luminosity] > 10 and [?FL_Rollo] eq "off") (set FL_Rollo Schlitz) DOELSEIF ([06:00|7] and [?FL_Rollo] eq "off") (set FL_Treppenlicht 20)
Die logische Denkweise sagt, dass die erste Bedingung geprüft wird, nur dann, wenn die erste nicht zutrifft, die zweite und nur dann, wenn auch die nicht zutrifft, die dritte. Fakt ist aber, dass bei Nichtzutreffen der ersten Bedingung die zweite und die dritte immer beide angetriggert werden und den Ausführungsteil ausführen, wenn [?GEN_Aussensensor:luminosity] > 10, sonst natürlich nur die dritte.
Normalerweise sollte bei [?GEN_Aussensensor:luminosity] > 10 nach der zweiten Bedingung Schluss sein. Der Zeittrigger in der dritten Bedingung sorgt aber wohl trotzdem für ein Ausführen. Darum habe ich in der dritten dann noch ein [?GEN_Aussensensor:luminosity] <= 10 ergänzt.
Zeitangaben im DOIF setzen interne Timer. Geprüft werden natürlich alle Bedingungen in den Zweigen. Im zweiten checkst du wochends um 6 Außenlicht und Rollo. Trifft alles zu, wird auf Schlitz gefahren. Wenn nicht, wird Zweig 3 gecheckt und ggf. ausgeführt. Der ist die Alternative zu Zweig 2 und kommt dann zur Anwendung, wenn Außenlicht < 11 ist. Alles logisch.
Würdest Du Zweig 3 und 2 tauschen, würde unabhängig vom Außenlicht immer Zweig 2 greifen (bei FL_Rollo off)...
Du meinst jetzt aber, Zweig drei wird ohne den Test auf Helligkeit auch bei Helligkeit >10 ausgeführt?
Das ist unlogisch ... :)
edit: falls DOIF zwei Timer setzt (für die beiden Zweige quasi als Wecksignal je einen), um damit die Zweige zwei und drei nacheinander zu prüfen, würden evtl. beide zutreffen und das DOIF zuerst auf 2, dann sofort auf 3 wechseln - faktisch beide ausführen. Dann führt aber das ELSE IF irgendwie logisch in die Irre... wäre praktisch eher ein DOALSOIF.
Und was sagt der Sprecher? :)
Zitat von: Pfriemler am 16 Mai 2015, 08:03:46
Zeitangaben im DOIF setzen interne Timer. Geprüft werden natürlich alle Bedingungen in den Zweigen. Im zweiten checkst du wochends um 6 Außenlicht und Rollo. Trifft alles zu, wird auf Schlitz gefahren. Wenn nicht, wird Zweig 3 gecheckt und ggf. ausgeführt. Der ist die Alternative zu Zweig 2 und kommt dann zur Anwendung, wenn Außenlicht < 11 ist. Alles logisch.
Würdest Du Zweig 3 und 2 tauschen, würde unabhängig vom Außenlicht immer Zweig 2 greifen (bei FL_Rollo off)...
Du meinst jetzt aber, Zweig drei wird ohne den Test auf Helligkeit auch bei Helligkeit >10 ausgeführt?
Das ist unlogisch ... :)
edit: falls DOIF zwei Timer setzt (für die beiden Zweige quasi als Wecksignal je einen), um damit die Zweige zwei und drei nacheinander zu prüfen, würden evtl. beide zutreffen und das DOIF zuerst auf 2, dann sofort auf 3 wechseln - faktisch beide ausführen. Dann führt aber das ELSE IF irgendwie logisch in die Irre... wäre praktisch eher ein DOALSOIF.
Und was sagt der Sprecher? :)
Zur Zeit wird für jede Zeitangabe ein separater Timer gesetzt. Geprüft wird grundsätzlich nur die Bedingung zum ausgelösten Timer.
Wenn man in zwei Bedingungen die gleiche Zeit angibt (hier 06:00 Uhr), so triggert das Modul zwei mal. Dabei ist bei gleicher Zeit die Reihenfolge des Triggerns nicht gewährleistet. Es kann also passieren, dass beim ersten Trigger Zweig 3 ausgeführt und beim zweiten Zweig 2.
Zukünftig will ich nur einen Timer für gleiche Zeit aufsetzen (damit würde man nur einmal triggern) und damit die Reihenfolge der Abarbeitung sicherstellen und es würde zum gleichen Zeitpunkt höchsten nur ein Zweig ausgeführt werden - der erste, für den die Bedingung wahr ist (wie man es eigentlich erwartet).
Gruß
Damian
Danke für die Bestätigung. Kann Dich nur ermutigen das umzusetzen. Bleibt zu hoffen, dass nur wenige dieses Verhalten vielleicht trickreich ausgenutzt haben und dann auf die Nase fallen. Rallis DOIF würde aber auch dann weiter funktionieren.
geht nich Gips nich ...
Zitat von: Pfriemler am 16 Mai 2015, 09:55:36
Danke für die Bestätigung. Kann Dich nur ermutigen das umzusetzen. Bleibt zu hoffen, dass nur wenige dieses Verhalten vielleicht trickreich ausgenutzt haben und dann auf die Nase fallen. Rallis DOIF würde aber auch dann weiter funktionieren.
geht nich Gips nich ...
Da die Reihenfolge der Abarbeitung bei gleicher Zeit nicht gewährleistet ist, kann man es eigentlich nicht sinnvoll ausnutzen. Will man jetzt schon die Reihenfolge sicherstellen, so muss man leicht versetzte Zeiten angeben z. B. 06:00 Uhr im zweiten Fall und 06:00:01 Uhr im dritten.
Gruß
Damian
Zitat von: Pfriemler am 15 Mai 2015, 22:13:13
Das DOIF ja, aber solange sich der State des DOIFs nicht ändert, (also auch wenn seine Bedingung immer und immer wieder zutrifft) wird sein Ausführungsteil auch nicht erneut ausgeführt. Außer es wäre "do always" gesetzt, was hier aber gerade keinen Sinn macht.
Ja klar. Die vorgeschlagene "Schaltung" konnte ich ohne Gerät nicht ausführlich testen. Es kommt nicht selten vor, dass in der Praxis unerwartete Effekte auftauchen. Im Event Monitor nachzuschauen, ist immer hilfsreich.
Zitat von: Pfriemler am 15 Mai 2015, 22:13:13
Im übrigen meine ich mich zu erinnern, dass das DOIF den State einnimmt, der nach den Bedingungszweigen als erstes zutrifft, alle anderen werden ignoriert.
Ja, theoretisch. Es wird im Commandref auch ausführlich beschrieben. Ich versuche jedoch, die Abhängigkeit der Reihenfolge zu vermeiden.
Zitat von: Pfriemler am 15 Mai 2015, 22:13:13
Wenn man die Bedingung nach "Leistung = 0" also vor der Abfrage "Leistung <5" einträgt, sollte es auch klappen.
Stimmt nicht! In diesem Beispiel ist die Reihenfolge irrelevant. Folgende Bedingung hat nicht zufällig ein "and":
DOELSEIF ([WM_SenPwr] < 5 and [?Waschmaschine] eq "running")
Gruss
flurin
@flurin: ich meinte das Beispiel aus #70 und Rallis Einwand in #72. Durch einen entsprechenden Tausch sollte sich das doch ändern? Oder führt wie aktuell bei den Zeiten ein Event als einziger Trigger eines Zweiges dazu, dass alle betreffenden Zweige geprüft werden, auch wenn bereits einer zutraf? Dann wäre ja hier das "DOALSOIF" genauso angebracht.
Elseif-Strukturen in anderen Sprachen arbeiten m.W. immer so, dass die erste erfolgreiche Bedingung abgearbeitet und in diesem Fall keine weiteren Bedingungen mehr geprüft werden.
geht nich Gips nich ...
Zitat von: Pfriemler am 16 Mai 2015, 11:51:39
@flurin: ich meinte das Beispiel aus #70 und Rallis Einwand in #72. Durch einen entsprechenden Tausch sollte sich das doch ändern? Oder führt wie aktuell bei den Zeiten ein Event als einziger Trigger eines Zweiges dazu, dass alle betreffenden Zweige geprüft werden, auch wenn bereits einer zutraf? Dann wäre ja hier das "DOALSOIF" genauso angebracht.
Elseif-Strukturen in anderen Sprachen arbeiten m.W. immer so, dass die erste erfolgreiche Bedingung abgearbeitet und in diesem Fall keine weiteren Bedingungen mehr geprüft werden.
geht nich Gips nich ...
Grundsätzlich gilt:
1.
Ein Trigger kann nur zur Ausführung
eines Zweiges führen.
2. Es werden
nur Bedingungen überprüft, wo der Trigger vorkommt (Device oder Zeit)
Gruß
Damian
Zitat von: Pfriemler am 16 Mai 2015, 11:51:39
@flurin: ich meinte das Beispiel aus #70 und Rallis Einwand in #72. Durch einen entsprechenden Tausch sollte sich das doch ändern? Oder führt wie aktuell bei den Zeiten ein Event als einziger Trigger eines Zweiges dazu, dass alle betreffenden Zweige geprüft werden, auch wenn bereits einer zutraf? Dann wäre ja hier das "DOALSOIF" genauso angebracht.
Elseif-Strukturen in anderen Sprachen arbeiten m.W. immer so, dass die erste erfolgreiche Bedingung abgearbeitet und in diesem Fall keine weiteren Bedingungen mehr geprüft werden.
geht nich Gips nich ...
@Pfriemler
In deinem Posting #82 hast du mich zitiert. Ich konnte aus deinem Text nicht ableiten, worauf du dich bezogen hast.
Aber jetzt ist es klar. Wie gesagt, die Abhängigkeit der Reihenfolge zu vermeiden, finde ich bei DOIF sinnvoll.
Zudem kann man ein DOIF aufteilen, wenn es Konflikte gibt (siehe auch defensives Programmieren).
Im Commandref heisst es:
Zitat
Syntax angelehnt an Verzweigungen if - elseif - ... - elseif - else in höheren Sprachen
DOIF hat jedoch zusätzliche Eigenschaften und verhält sich nicht wie das "if" in höheren Sprachen.
Zitat von: flurin am 16 Mai 2015, 12:20:08
DOIF hat jedoch zusätzliche Eigenschaften und verhält sich nicht wie das "if" in höheren Sprachen.
ja, den Unterschied machen Trigger aus, die eine Aktion auslösen - die gibt es in höheren Sprachen bei "if" so nicht. Das macht die Sache etwas komplexer.
Gruß
Damian
Danke für den regen Austausch ;).
Also rein logisch betrachtet wäre es für die Abarbeitung eines DOIF sinnvoller, erst mal alle in der DOIF-Def vorhandenen Trigger "zu sammeln" bzw. auch zu konsolidieren (Stichwort gleiche Zeitangaben als Trigger) und dann rein strukturiert die Zweige mit ihren logischen Bedingungsprüfungen jeweils vom Start weg abzuarbeiten - egal, ob ein Trigger bspw. erst im dritten DOELSEIF auftaucht.
Dass das in der Programmierung komplex und nicht einfach ist, glaube ich gerne :).
Ich wiederhole mich: Zuerst ist man geneigt zu vermuten, das stets das gesamte DOIF gecheckt wird und als Trigger jedes irgendwo als Trigger definiertes Event im DOIF dient (so wie Ralli es eben vorschlägt). Wer "ElseIf" liest und es aus anderen Sprachen kennt, ist dann doch verwundert, wenn sich ein DOELSEIF nicht genauso verhält, wie es die Beispiele mit den Triggerzeiten und auch der Umstand, dass nur Bedingungszweige gecheckt werden, in denen der Trigger vorkommt, zeigen. DOIF verstehe ich stattdessen also als eine Sammlung von Bedingungsgruppen, deren letztes Zutreffen sich das DOIF zudem als Zustand merkt, und zwar jeweils nur den letzten, auch wenn sich mehrere Zweige quasi gleichzeitig als wahr erweisen und möglichweise auch ausgeführt werden.
ABER: Man kann hier nicht alles gleichzeitig haben, und es gibt ja genügend vernünftige Gründe es so zu tun wie es Damian umgesetzt hat, und mit
Zitat... die Abhängigkeit der Reihenfolge zu vermeiden, finde ich bei DOIF sinnvoll.
hat flurin auch absolut recht. Eine zusätzliche Abfrage in der entsprechenden Bedingungsgruppe kann viel Klarheit schaffen und tut niemandem weh. Ganz alternativ könnte man ja etwa bei dem Rollo-Beleuchtungs-Beispiel auch auf wochenends 6 Uhr triggern und den Rollozustand abfragen und erst im Ausführungsteil mit einem IF auf die Beleuchtungsstärke zwischen Rollobewegung und Treppenhausbeleuchtung entscheiden.
Etwas Offtopic:
Weiterhin: Eine ElseIf-Gruppe in anderen Sprachen hinterlässt nach ihrer Abarbeitung keine Spuren. DOIF ist ja zusätzlich noch ein Zustandsspeicher, und der Zustand des DOIF vor der erneuten Triggerung ist ohne "do always" auch eine versteckte Ausführungsbedingung. Das und der Umstand, dass die in den Zweigen formulierten Bedingungen aus völlig unterschiedlichen Kategorien stammen können, erlaubt einerseits interessante Zusammenfassungen von Automatisierungsvorgängen unter einem Dach, erlaubt aber immer noch nicht beliebige Konstruktionen als Zustandsspeicher (was kein Fehler von DOIF ist).
ZitatZudem kann man ein DOIF aufteilen, wenn es Konflikte gibt (siehe auch defensives Programmieren).
Genau. Ich habe mit meinem Garagentor versucht, dessen Zustände closed, opening, opened, closing und stopped (als Zwischenhalt unterwegs) durch die Abfrage von zwei Motorrelais und zwei Endlagenschaltern in ein DOIF zu pressen. Hierbei alle Eventualitäten zu berücksichtigen, etwa dass die Relais nicht gleich schnell schalten und der Motor erst nach dem Erreichen des Endlagenschalters stoppt, war auch mit gezielten waits nicht so trivial zu erreichen - letztlich wurde je ein DOIF für die Motorbewegung und ein weiteres für den Torzustand (closed, between, opend) und jeweilige sets auf einen Dummy die einfachere Lösung.
Ansonsten liebe ich gerade den Zustandsspeicher des DOIF und seine hervorragenden Formatierungsmöglichkeiten. Dass sich ganz ohne Zusatzdummys in der Weboberfläche ein DOIF hinter einer klarschriftlichen Bezeichnung (per alias) und einer Zustandsbeschreibung (per Attribut cmdstate und ggf. state) verbergen kann, nutze ich so oft es irgend geht.
Pfriemler, mein Beispiel-DOIF habe ich hier nur angeführt, um das "Problem" aufzuzeigen. Natürlich habe ich das längst um eine entsprechende Abfrage ergänzt und somit das "Problem" umschifft.
Letztendlich bleibt tatsächlich der letztendliche Unterschied zu einem klassischen elsif einer Programmiersprache. Man muss sich eben klar darüber sein, dass es in einem DOIF bislang scheinbar kein klassisches/echtes (DO)ELSIF gibt.
Damit wir uns recht verstehen: ich bin sehr froh über das Modul und noch mehr über Damians "Ansprechbarkeit"! Was ich aufzeigte, soll auch kein Gemecker sein - ich bin halt drüber gestolpert und wollte das hier kundtun, falls andere, die elsif kennen, hier ebenfalls an sich zweifeln :).
Zitat von: Ralli am 16 Mai 2015, 13:58:38
Pfriemler, mein Beispiel-DOIF habe ich hier nur angeführt, um das "Problem" aufzuzeigen. Natürlich habe ich das längst um eine entsprechende Abfrage ergänzt und somit das "Problem" umschifft.
Letztendlich bleibt tatsächlich der letztendliche Unterschied zu einem klassischen elsif einer Programmiersprache. Man muss sich eben klar darüber sein, dass es in einem DOIF bislang scheinbar kein klassisches/echtes (DO)ELSIF gibt.
Damit wir uns recht verstehen: ich bin sehr froh über das Modul und noch mehr über Damians "Ansprechbarkeit"! Was ich aufzeigte, soll auch kein Gemecker sein - ich bin halt drüber gestolpert und wollte das hier kundtun, falls andere, die elsif kennen, hier ebenfalls an sich zweifeln :).
Ich hatte schon mal geschrieben: Am Anfang der Entwicklungsphase des Moduls hat ein beliebiger Trigger immer zur Abarbeitung aller Zweige der Reihe nach geführt. Das war auch trivial zu programmieren, weil man sich nicht merken musste, welche Devices in welchen Bedingung steckten. Diese Vorgehensweise habe ich allerdings bereits vor der Veröffentlichen direkt verworfen, weil meine definierten DOIF-Module etwas taten, was ich eigentlich nicht wollte - Zweige auszuführen, die mit dem Trigger nichts zu tun hatten. Es zeigte sich nämlich, dass man beim Definieren einer Bedingung mit ihrem Ausführungsteil erst mal an die Sachen denkt, die in dieser Bedingung vorkommen und nicht an die Sachen, die in anderen Bedingung vorkommen. Das Problem zeigt sich immer noch beim DOELSE-Fall, an den viele nicht denken, der immer dann vorkommt, wenn die zu prüfenden Zweige nicht wahr sind - vor allem dann, wenn es mehrere DOELSEIF-Fälle gibt.
Gruß
Damian
Zitat...weil meine definierten DOIF-Module etwas taten, was ich eigentlich nicht wollte - Zweige auszuführen, die mit dem Trigger nichts zu tun hatten.
Darauf könnte ich antworten: Dann wäre zu überlegen, ob diese Zweige auch richtigerweise in dieses DOIF gehören. Denn eine Konstruktion wie (nur logisch gesprochen, nicht syntaktisch richtig)
DOIF ([Lichtdraußen] < x)(set Außenlicht on)
DOELSEIF ([LichtDrinnen] < y)(set Innenlicht on)
wird als Sammlung von Bedingungen wie gewünscht funktionieren, wenn die Zweige nur von den entsprechenden Triggern bedient werden: Wird's draußen dunkel, schalte das Licht ein, wird's drinnen dunkel, schalte das Licht ein. Beim Abklappern des gesamten DOIF nach dem Auftreten eines der beiden Trigger würde das Innenlicht aber nie angehen, wenn es zuerst draußen dunkel wird, weil die erste Bedingung wahr ist - und Schluss. Man kann sich aber an dieser Stelle trefflich streiten, ob diese beiden eigentlich voneinander völlig unabhängigen Fälle ins gleiche DOIF gehören.
Abgesehen davon muss ich diese Aussagen:
ZitatDamit wir uns recht verstehen: ich bin sehr froh über das Modul und noch mehr über Damians "Ansprechbarkeit"! Was ich aufzeigte, soll auch kein Gemecker sein - ich bin halt drüber gestolpert und wollte das hier kundtun, falls andere, die elsif kennen, hier ebenfalls an sich zweifeln
mal ganz dick unterschreiben. Wir können uns nur wünschen, dass es so bleibt!
Zitat von: Pfriemler am 16 Mai 2015, 17:31:10
Darauf könnte ich antworten: Dann wäre zu überlegen, ob diese Zweige auch richtigerweise in dieses DOIF gehören. Denn eine Konstruktion wie (nur logisch gesprochen, nicht syntaktisch richtig)
DOIF ([Lichtdraußen] < x)(set Außenlicht on)
DOELSEIF ([LichtDrinnen] < y)(set Innenlicht on)
wird als Sammlung von Bedingungen wie gewünscht funktionieren, wenn die Zweige nur von den entsprechenden Triggern bedient werden: Wird's draußen dunkel, schalte das Licht ein, wird's drinnen dunkel, schalte das Licht ein. Beim Abklappern des gesamten DOIF nach dem Auftreten eines der beiden Trigger würde das Innenlicht aber nie angehen, wenn es zuerst draußen dunkel wird, weil die erste Bedingung wahr ist - und Schluss. Man kann sich aber an dieser Stelle trefflich streiten, ob diese beiden eigentlich voneinander völlig unabhängigen Fälle ins gleiche DOIF gehören.
DOIF unterscheidet nicht grundsätzlich zwischen Zeit- bzw. Device-Triggerung.
Bei diesem Beispiel gehören beide Bedingungen in ein Modul, weil es sich um das gleiche Rollo handelt. Nun möchte jemand, dass es bei Helligkeit morgens hoch fährt und prinzipiell um 19:00 Uhr runter fährt, ob es noch hell ist oder nicht:
DOIF ([hell] eq "on") (set rollo hoch)
DOELSEIF ([19:00]) (set rollo runter)
Um 19:00 Uhr würde der Rollladen aber nicht runterfahren, wenn es noch hell ist.
Gruß
Damian
Hallo. Habe fehlermeldung bei folgendem doif.
([ mytwilight:akt.event] eq "ss") (set Steckdose1 on-till 22:30,define next2 at +00:00:30 set Vorgarten_links1 on-till 22:32,define next3 at +00:01:00 set Vorgarten_Haus on-till 22:20,define next4 at +00:01:30 set Antikleuchte on-till 23:00,define next5 at +00:15:00 set Poolbeleuchtung on-till 22:31,set Dunkelheit on)
Error: define next5 already defined, delete it first. Warum? Kann kein next5 finden
Sent from my OPO
Ernstlich? Dein DOIF definiert zur Ausführungzeit einmalige 5 at's, die sich nach Ausführung selbst löschen. Taucht die Fehlermeldung zur Ausführungszeit auf (z.B. im Log), dann war das betreffende at noch nicht aktiv und existiert demnach noch. Einmalige at tauchen nicht in der fhem.cfg, sondern nur im statefile auf. "list next.*" sollte Dir alle noch aktiven (wartenden) at's mit dem Namen auf der Kommandoebene zeigen.
ja, wirklich. Fehlermeldung steht schon wieder an.
Ich denke kommt bei anlegen von next5. komisch das aber fehlerfrei geschalten wird.
vielleicht nur ein bug von DOIF ?
list next5 ergibt kein ergebnis.
gruss
Es könnte daran liegen, dass ein weiterer auslösender Event vor Ablauf der 15 Minuten das DOIF erneut getriggert hat. Setze mal im DOIF Verbose auf 5.
Ohne dass ich jetzt alles hier mitverfolgt hätte: Könnte hier das neue "defmod" eine Lösung darstellen?
http://forum.fhem.de/index.php/topic,36326.0.html (http://forum.fhem.de/index.php/topic,36326.0.html)
@satprofi
Was ist der Zweck der Verzögerungen? Evtl. geht es ohne "at".
Gruss
flurin
Zitat von: Ralli am 18 Mai 2015, 07:19:13
Es könnte daran liegen, dass ein weiterer auslösender Event vor Ablauf der 15 Minuten das DOIF erneut getriggert hat. Setze mal im DOIF Verbose auf 5.
Hallo.
Habe Fehler gefunden, doAlways ist hier fehl am Platz........
gruss
Das wiederum glaube ich nicht - zumindest nicht mit der momentanen Definition. Denn Dein DOIF kann bislang nur genau einen Status annehmen und wird daher auch nur ein einziges mal und danach nie wieder das CMD_1 ausführen.
Dürfte aber so gewesen sein.
Habe anderes reading als Test für triggerung genommen. Und da kam die meldung gleich nach änderung des readings, obwohl schon next* definiert waren.
Und ich denke das myTwilight auch regelmässig triggert.
werde heute abend genaueres wissen, wenn trigger anstöst.
Zitat von: satprofi am 18 Mai 2015, 14:08:00
Dürfte aber so gewesen sein.
Habe anderes reading als Test für triggerung genommen. Und da kam die meldung gleich nach änderung des readings, obwohl schon next* definiert waren.
Und ich denke das myTwilight auch regelmässig triggert.
werde heute abend genaueres wissen, wenn trigger anstöst.
Wenn diese Meldung "define next5 already defined, delete it first." kommt, dann ist klar, dass im DOIF-Modul das at-Define wieder aufgesetzt wird, obwohl das vorherige at noch nicht abgearbeitet ist - das hat nicht viel mit DOIF zu tun. Wie schon vorgeschlagen, das neue defmod statt define verwenden, dann wird at neu aufgesetzt, obwohl das alte noch nicht ausgeführt ist. Am besten aber, du findest heraus, warum dein Modul öfters getriggert wird, als du denkst.
Gruß
Damian
Das mit der Zeit klingt spannend.
Läßt sich folgendes realisieren: wenn meine Wohnungstür geöffnet wird (W.Tuer) und ein bestimmtes Gerät nicht innerhalb 60 Sekunden eingeschaltet wird (Strom), dann soll eine Lampe (Licht) eingeschaltet werden?
Dabei muß berücksichtigt werden daß die Tür in der Zeit auch schon wieder geschlossen sein kann.
Stelle ich mir als eine Art Einbruchschutz vor.
Zitat von: Christian72D am 28 Oktober 2015, 17:16:08
Das mit der Zeit klingt spannend.
Läßt sich folgendes realisieren: wenn meine Wohnungstür geöffnet wird (W.Tuer) und ein bestimmtes Gerät nicht innerhalb 60 Sekunden eingeschaltet wird (Strom), dann soll eine Lampe (Licht) eingeschaltet werden?
Dabei muß berücksichtigt werden daß die Tür in der Zeit auch schon wieder geschlossen sein kann.
Stelle ich mir als eine Art Einbruchschutz vor.
Das, was du vorhast hat eigentlich nichts mit den neuen (inzwischen alten) Zeit-Features zu tun.
define di DOIF ([W.Tuer] eq "opened") (set licht on) DOELSEIF ([Strom] eq "on")
attr di wait 60Das wait-Attribut gab es immer schon.
Gruß
Damian
Zitat von: Damian am 28 Oktober 2015, 21:20:20
Das, was du vorhast hat eigentlich nichts mit den neuen (inzwischen alten) Zeit-Features zu tun.
define di DOIF ([W.Tuer] eq "opened") (set licht on) DOELSEIF ([Strom] eq "on")
attr di wait 60
Das wait-Attribut gab es immer schon.
Aber genau das wird ja nicht funktionieren, oder?
Christian72D hat ja erwähnt, dass der Alarm auch dann ausgelöst werden soll, wenn die Tür wieder geschlossen wird.
In deinem Beispiel würde das Licht nicht angehen, wenn die Tür innerhalb von 60sec wieder geschlossen wird.
Zitat von: FunkOdyssey am 29 Oktober 2015, 10:44:07
Aber genau das wird ja nicht funktionieren, oder?
Christian72D hat ja erwähnt, dass der Alarm auch dann ausgelöst werden soll, wenn die Tür wieder geschlossen wird.
In deinem Beispiel würde das Licht nicht angehen, wenn die Tür innerhalb von 60sec wieder geschlossen wird.
Ich habe nichts von "Ausschalten eines Alarms" in seiner Anforderung gesehen. Für mich ist Lampe = Alarm.
Gruß
Damian
Zitat von: Christian72D am 28 Oktober 2015, 17:16:08Dabei muß berücksichtigt werden daß die Tür in der Zeit auch schon wieder geschlossen sein kann.
Ich hatte das hier so verstanden.
Hallo Damian,
steh grad bisschen auf dem Schlauch, ich möchte zu einer Zeit welche durch eine Perl-Funktion vorgegeben ist mit DOIF schalten, der Rückgabewert dieses Perlfunktion kann sich allerdings jederzeit ändern, und sollte zumindest alle X Minuten aktualisiert werden.
Wenn ich jetzt
([{fn()}]) (set dummy on)
mache, wird das nur bei einem modify aktualisiert.
So
([{fn("[+10]")}]) (set dummy on)
habe ich es auch schonmal probiert, aktualisiert allerdings trotzdem nicht (hab ich in nem anderen thread gefunden).
i.M. bin ich bei dieser Lösung mit einem zusätzlichen dummy angekommen, was nicht gerade hübsch ist aber zumindest funktioniert :-\
([+10]) (set timeDummy {fn()}) DOELSEIF ([[timeDummy]]) (set dummy on)
Hast du einen Tipp wie das evtl. ohne zwischenspeichern in einem dummy/reading lösbar ist?
Gruß
Claudiu
Zitat von: rapster am 02 November 2015, 23:00:16
Hallo Damian,
steh grad bisschen auf dem Schlauch, ich möchte zu einer Zeit welche durch eine Perl-Funktion vorgegeben ist mit DOIF schalten, der Rückgabewert dieses Perlfunktion kann sich allerdings jederzeit ändern, und sollte zumindest alle X Minuten aktualisiert werden.
Wenn ich jetzt
([{fn()}]) (set dummy on)
mache, wird das nur bei einem modify aktualisiert.
So
([{fn("[+10]")}]) (set dummy on)
habe ich es auch schonmal probiert, aktualisiert allerdings trotzdem nicht (hab ich in nem anderen thread gefunden).
i.M. bin ich bei dieser Lösung mit einem zusätzlichen dummy angekommen, was nicht gerade hübsch ist aber zumindest funktioniert :-\
([+10]) (set timeDummy {fn()}) DOELSEIF ([[timeDummy]]) (set dummy on)
Hast du einen Tipp wie das evtl. ohne zwischenspeichern in einem dummy/reading lösbar ist?
Gruß
Claudiu
Wann eine Funktion ihre Ausgabe ändert, kann das Modul natürlich nicht erkennen. Deswegen ist der Umweg über einen Dummy wohl die richtige Lösung.
Gruß
Damian
Ok danke, dachte evtl. gibts da irgend ein attr, trigger-Anweisung oder sonstiges um die perl expressions regelmäßig auswerten zu lassen.
Gruß
Claudiu
Ich habe eine Frage zu den Zeitfunktionen. Ich möchte gern um 6 und um 18 Uhr etwas auslösen und dachte an
DOIF ([06:00] or [18:00]) (set blabla)
Allerdings wird bei mir der Befehl am Ende nicht ausgeführt. In den Readings wird er aber ,,angekündigt". Ist denn wenigstens erstmal die Syntax in Ordnung?
Attribut do always setzen, dann geht das...
Oh Mist, das hatte ich doch gerade gelesen mit dem do always und dem Streit darüber...
@damian: Könnte man das nicht immer setzen? Oder spricht da etwas dagegen?
Zitat von: andies am 18 Dezember 2017, 14:13:54
Oh Mist, das hatte ich doch gerade gelesen mit dem do always und dem Streit darüber...
@damian: Könnte man das nicht immer setzen? Oder spricht da etwas dagegen?
wenn all deine DOIFs z.B. mit DO_ anfangen, könntest du auf global defined triggern...
define no1 notify global:DEFINED.DO_.* attr $EVTPART1 do always
Hallo Leute habe mir die Schreibweise von der ersten Seite genommen. Aber glaube nicht das ich es so richtig geschrieben habe. Den er sagt ich habe auch einen Fehler. Denke auch in den Klammern. Aber welche sind den falsch oder ejar zu viel.
([?20:00-03:30]
and
[avr:power] eq "off")
(set Erdgeschoss_Licht off )
DOELSEIF
([([22:30]+int(rand(1800))) |Mo Di Mi Do So]) or ([([22:20]+int(rand(7200)))] |Fr Sa])
and
[Eltern] eq "absend"
and
[Babysitter] eq "weg")
(set Erdgeschoss_Licht off )
([?20:00-03:30]
and
[avr:power] eq "off")
(set Erdgeschoss_Licht off )
DOELSEIF
(([([22:30]+int(rand(1800))) |Mo Di Mi Do So] or [([22:20]+int(rand(7200)))|Fr Sa])
and
[Eltern] eq "absend"
and
[Babysitter] eq "weg")
(set Erdgeschoss_Licht off )
Je nachdem woher der Wert für [Eltern] kommt, könnte es sein, dass sie nie "absend" sind... ;)
@Damian
Danke für den Code werde ihn mal ausprobieren.
@Pfriemler
Sind unsere Handys die über die Fritzbox laufen und in einer Strucrure untergebracht sind. Das hat eigentlich immer funktoniert. Wieso meinst du den das das nicht funkoniert?
Structures bekommen die Werte in der Regel anderweitig zugeliefert. Und abwesende Geräte sind i.d.R. absent, es sei denn Du hast selbst eine Umbenennung eingebaut
So habe es nochmal probiert habe das mit den Eltern auch rausgenommen und habe es durch mich und Frau auf present geändert.
Es schaltet nun aber dauerhaft obwohl wir zuhause sind und AVR:power on ist.
Internals:
CFGFN
DEF ([?20:00-03:30]
and
[avr:power] eq "off" and [Stefan] eq "present" or [Christin] eq "present")
(set Erdgeschoss_Licht off )
DOELSEIF
(([([22:00]+int(rand(1800))) |Mo Di Mi Do So]) or ([([22:20]+int(rand(7200))) |Fr Sa])
and
[Stefan] eq "absent" and [Christin] eq "absent"
and
[avr:power] eq "off")
(set Erdgeschoss_Licht off )
FUUID 5ec6df24-f33f-faf7-3710-eae47bcededb8c02
MODEL FHEM
NAME Licht_steuerung
NOTIFYDEV global,Stefan,Christin,avr
NR 16776
NTFY_ORDER 50-Licht_steuerung
STATE cmd_1
TYPE DOIF
VERSION 20811 2019-12-22 17:45:08
READINGS:
2020-05-24 22:45:12 Device Christin
2020-05-24 22:44:09 cmd 1
2020-05-24 22:44:09 cmd_event Stefan
2020-05-24 22:44:09 cmd_nr 1
2020-05-24 22:45:12 e_Christin_STATE present
2020-05-24 22:45:09 e_Stefan_STATE present
2020-05-24 22:43:58 mode enabled
2020-05-24 22:44:09 state cmd_1
2020-05-24 22:43:58 timer_01_c01 25.05.2020 20:00:00
2020-05-24 22:43:58 timer_02_c01 25.05.2020 03:30:00
2020-05-24 22:43:58 timer_03_c02 25.05.2020 22:26:12|MoDiMiDoSo
2020-05-24 22:43:58 timer_04_c02 24.05.2020 22:52:32|FrSa
Regex:
accu:
cond:
Christin:
0:
&STATE ^Christin$
1:
&STATE ^Christin$
Stefan:
0:
&STATE ^Stefan$
1:
&STATE ^Stefan$
avr:
0:
power ^avr$:^power:
1:
power ^avr$:^power:
attr:
cmdState:
wait:
waitdel:
condition:
0 ::DOIF_time($hash,0,1,$wday,$hms) and ::ReadingValDoIf($hash,'avr','power') eq "off" and ::InternalDoIf($hash,'Stefan','STATE') eq "present" or ::InternalDoIf($hash,'Christin','STATE') eq "present"
1 (::DOIF_time_once($hash,2,$wday,"MoDiMiDoSo")) or (::DOIF_time_once($hash,3,$wday,"FrSa")) and ::InternalDoIf($hash,'Stefan','STATE') eq "absent" and ::InternalDoIf($hash,'Christin','STATE') eq "absent" and ::ReadingValDoIf($hash,'avr','power') eq "off"
days:
2 MoDiMiDoSo
3 FrSa
do:
0:
0 set Erdgeschoss_Licht off
1:
0 set Erdgeschoss_Licht off
2:
helper:
DEVFILTER ^global$|^Stefan$|^avr$|^Christin$
NOTIFYDEV global|Stefan|avr|Christin
event present,presence: present
globalinit 1
last_timer 4
sleeptimer -1
timerdev Christin
timerevent present,presence: present
triggerDev Christin
timerevents:
present
presence: present
timereventsState:
state: present
presence: present
triggerEvents:
present
presence: present
triggerEventsState:
state: present
presence: present
internals:
all Stefan:STATE Christin:STATE
interval:
0 -1
1 0
intervalfunc:
localtime:
0 1590429600
1 1590370200
2 1590438372
3 1590353552
readings:
all avr:power
realtime:
0 20:00:00
1 03:30:00
2 22:26:12
3 22:52:32
time:
0 20:00:00
1 03:30:00
2 ([22:00]+int(rand(1800)))
3 ([22:20]+int(rand(7200)))
timeCond:
0 0
1 0
2 1
3 1
timer:
0 0
1 0
2 0
3 0
timers:
1 2 3
trigger:
triggertime:
1590353552:
localtime 1590353552
hash:
1590370200:
localtime 1590370200
hash:
1590429600:
localtime 1590429600
hash:
1590438372:
localtime 1590438372
hash:
uiState:
uiTable:
Attributes:
room Licht
Irgendwo habe ich einen schreibfehler? Oder nimmt der einen wert irgendwo falsch??
Selbst wenn ich Set checkall ausführe. Er springt dann in CMD1 da dürfte er doch eigentlich nicht reinspringen.
danke
([?20:00-03:30] and [avr:power] eq "off" and [Stefan] eq "present" or [Christin] eq "present")
and or Vorrang. Was Du geschrieben hast, ist wie:
(
([?20:00-03:30] and [avr:power] eq "off" and [Stefan] eq "present")
or [Christin] eq "present"
)
Jedes mal wenn Christin "present" meldet, ist die Bedingung 1 wahr, egal den Rest.
@ amenomade
Ich habe es geändert wie du es mir geschrieben hast. Leider nicht geklappt. Und ja du hast recht er meldet die ganze Zeit Christin present.
Und schaltet daher.
Ich habe überhaupt keine Lösung geschrieben. Ich habe nur deinen Fehler anders dargestellt, um besser zu zeigen, warum es ein Fehler ist. Beide "code" Abschnitte in meinem vorherigen Post sind absolut gleichwertig und führen zum gleichen Ergebnis.
Natürlich musst Du die Klammern anders setzen, damit es funktioniert:
xxx and xxx and (xxx or xxx)
Zitat von: Damian am 29 März 2015, 22:16:05
define Zeit dummy
set Zeit 10:00
DOIF ([([Zeit]+int(rand(600)))]) (set bla on)
oder relative Angaben: hier wird alle 5 Minuten getriggert
set Zeit 00:01
DOIF ([+([Zeit]+[00:04])]) (set bla on)
Hier eine Kombination mit Zeitintervallen: Hier von 09:55 bis 10:05 am Freitag
set Zeit 10:00
DOIF ([([Zeit]-[00:05]) - ([Zeit]+[00:05])]|5]) (set bla on)
Man kann beliebig Zeitangaben mit Perlfunktionen und Readings bzw. Stati kombinierten. Da auch hier der Perlinterpreter zum Zuge kommt, sind die Möglichkeiten Zeit zu berechnen unbegrenzt.
Ich habe versucht das anzuwenden:
define Wecker dummy
setreading Wecker alarm 05:45:00
([[Wecker:alarm]|AT]
and [?[Wecker:alarm]-{sunrise_abs(1800)}]) (
set blabla on
)
aber das funktioniert leider nicht richtig
timer_01_c01 25.06.2020 05:45:00|AT
timer_02_c01 24.06.2020 05:45:00
Der Timer aus dem reading bleibt immer eine Tag in der Vergangenheit hängen, während sunrise mit dem neuen Datum rechnet - somit ist das Intervall
[?[Wecker:alarm]-{sunrise_abs(1800)}] immer wahr. :(
Wie funktioniert das richtig...?
Danke und Gruß
cRossi
Das ist alles ok, der Trigger kommt jeden Tag, das Setzen beider Grenzen bei Zeitintervallen wird immer erst am Ende des Zeitintervalls gesetzt.
Hmm, ist irgendwie nicht ganz mein Verständnis, dass hier das Datum in der Zeitberechnung enthalten ist - denn wenn ich anstelle des Readings die Zeit "05:45" direkt eingebe funktioniert das Spiel ja komischer Weise richtig... ???
Wie bekomme ich das denn dann hin das der Wecker nur vor Sonnenaufgang angeht und zwar immer zu einer bestimmten Zeit die ich über ein Reading ändern kann?
Danke und Gruß
cRossi
Zitat von: cRossi am 26 Juni 2020, 10:29:35
Hmm, ist irgendwie nicht ganz mein Verständnis, dass hier das Datum in der Zeitberechnung enthalten ist - denn wenn ich anstelle des Readings die Zeit "05:45" direkt eingebe funktioniert das Spiel ja komischer Weise richtig... ???
Wie bekomme ich das denn dann hin das der Wecker nur vor Sonnenaufgang angeht und zwar immer zu einer bestimmten Zeit die ich über ein Reading ändern kann?
Danke und Gruß
cRossi
Das, was ich gesagt habe, gilt nur für Zeitintervalle. Beim normalen Zeittrigger wird die neue Zeit zum Triggerzeitpunkt berechnet.
Nicht wirklich hilfreich, außerdem geht es komischerweise wenn ich die Zeit auch im Intervall eintrage, aber danke dann bastel ich mir was anderes
Ich glaube wir reden aneinander vorbei.
1.) Die Wahrheit eines Zeitintervalls ist nur abhängig von der Uhrzeit und nicht vom Datum.
2.) Ein indirekter Timer (auch Zeitintervallgrenzen) werden immer! sofort aktualisiert, wenn sich die Zeitangabe ändert.
Ok, dann mal anders gefragt:
Wie sieht eine Zeit-Bedingung aus die abfragt ob sunrise größer bzw. kleiner als eine definierte Zeit ist?
Das hier funktioniert ja leider auch nicht:
(... [?[Wecker:alarm] le {sunrise_abs(1800)}]) ...
Dann eher
([[wecker:alarm]|AT] and [?wecker:alarm] le {sunrise_abs(1800)}) (
set blabla on
)
da der Vergleichoperator le Zeichen vergleicht (lexikografisch), solltest du wecker:alarm im Format hh:mm:ss setzen.
Ich habe auch mit der Zeitberechnung getestet und komme zu keinem positiven Ergebnis.
Ich habe setreading di_KinderZimmer_Rolladen StartLangsam 09:30:00 gesetzt. Leider wird der Wert aber als 0 erkannt.
setreading di_KinderZimmer_Rolladen StartLangsam 09:30:00
ergibt dann
timer_10_c14 03.07.2020 00:10:00
Hier noch das ganze Listing:
Internals:
DEF ([06:15 | AT ] and [JasminFrei] eq "0" and ::isday and [KinderZimmer_Rolladen_Balkon:pct] < 20)
(set KinderZimmer_Rolladen_Balkon 20)
DOELSEIF ([({sunrise(0,"08:30", "9:00")}) | 7] and [wech] eq "wech")
(set KinderZimmer_Rolladen_Fenster on,
set KinderZimmer_Rolladen_Balkon on)
DOELSEIF ([({sunrise(0,"07:30", "9:00")}) | 6] and [wech] eq "wech")
(set KinderZimmer_Rolladen_Fenster on,
set KinderZimmer_Rolladen_Balkon on)
DOELSEIF ([({sunrise(0,"07:30", "9:00")} ) | AT ] and [wech] eq "wech")
(set KinderZimmer_Rolladen_Fenster on,
set KinderZimmer_Rolladen_Balkon on)
DOELSEIF ([({sunset(-600, "16:00", "22:00")} ) ] and [KinderZimmer_Balkontuer:state] eq "open" and [KinderZimmer_Rolladen_Balkon:pct] > 50)
(set KinderZimmer_Rolladen_Fenster off,
set KinderZimmer_Rolladen_Balkon 50,
setreading di_KinderZimmer_Rolladen Balkon soll_zu)
DOELSEIF ([({sunset(-600, "16:00", "22:00")} ) ] and [KinderZimmer_Balkontuer:state] eq "open" and [KinderZimmer_Rolladen_Balkon:pct] <= 50)
(set KinderZimmer_Rolladen_Fenster off)
DOELSEIF ([({sunset(-600, "16:00", "22:00")} ) ] and [KinderZimmer_Balkontuer:state] eq "closed")
(set KinderZimmer_Rolladen_Fenster off,
set KinderZimmer_Rolladen_Balkon off)
DOELSEIF ([({sunset(-600, "16:00", "22:00")} ) ] and [KinderZimmer_Balkontuer:state] eq "tilted" and [KinderZimmer_Rolladen_Balkon:pct] > 10)
(set KinderZimmer_Rolladen_Fenster off,
set KinderZimmer_Rolladen_Balkon 10,
setreading di_KinderZimmer_Rolladen Balkon soll_zu)
DOELSEIF ([({sunset(-600, "16:00", "22:00")} ) ] and [KinderZimmer_Balkontuer:state] eq "tilted" and [KinderZimmer_Rolladen_Balkon:pct] <= 10)
(set KinderZimmer_Rolladen_Fenster off,
set KinderZimmer_Rolladen_Balkon off)
DOELSEIF ([KinderZimmer_Balkontuer:state] eq "closed" and [di_KinderZimmer_Rolladen:Balkon] eq "soll_zu")
(set KinderZimmer_Rolladen_Balkon off,
setreading di_KinderZimmer_Rolladen Balkon zu)
DOELSEIF ([Temp_outside:temperature] > 25 and [KinderZimmer_Rolladen_Fenster:pct] > 40 and [KinderZimmer_Rolladen_Fenster:UserMode] ne "manuell")
(set KinderZimmer_Rolladen_Fenster 40)
DOELSEIF ([Temp_outside:temperature] > 25 and [KinderZimmer_Rolladen_Balkon:pct] > 40 and [KinderZimmer_Rolladen_Balkon:UserMode] ne "manuell")
(set KinderZimmer_Rolladen_Balkon 40)
DOELSEIF ([di_KinderZimmer_Rolladen:StartLangsam ] and [JasminFrei] eq "1" and ::isday and [KinderZimmer_Rolladen_Balkon:pct] < 25)
(set KinderZimmer_Rolladen_Balkon 25)
DOELSEIF ([di_KinderZimmer_Rolladen:StartLangsam | AT ] + [00:10] and [JasminFrei] eq "1" and ::isday and [KinderZimmer_Rolladen_Balkon:pct] < 50)
(set KinderZimmer_Rolladen_Balkon 50)
DOELSEIF ([di_KinderZimmer_Rolladen:StartLangsam | AT ] + [00:20] and [JasminFrei] eq "1" and ::isday and [KinderZimmer_Rolladen_Balkon:pct] < 75)
(set KinderZimmer_Rolladen_Balkon 75)
DOELSEIF ([di_KinderZimmer_Rolladen:StartLangsam | AT ] + [00:30] and [JasminFrei] eq "1" and ::isday and [KinderZimmer_Rolladen_Balkon:pct] < 100)
(set KinderZimmer_Rolladen_Balkon 100,
set KinderZimmer_Rolladen_Fenster on)
FUUID 5c4b3ffe-f33f-78f8-d9d1-105e980cbe03d91f
MODEL FHEM
NAME di_KinderZimmer_Rolladen
NOTIFYDEV KinderZimmer_Rolladen_Fenster,global,di_KinderZimmer_Rolladen,wech,KinderZimmer_Rolladen_Balkon,Temp_outside,JasminFrei,KinderZimmer_Balkontuer
NR 549
NTFY_ORDER 50-di_KinderZimmer_Rolladen
STATE initialize
TYPE DOIF
VERSION 22030 2020-05-25 14:10:16
READINGS:
2020-04-26 21:50:35 Balkon zu
2020-07-02 11:10:29 Device Temp_outside
2020-07-02 11:05:20 StartLangsam 09:30:00
2020-07-02 08:47:00 e_KinderZimmer_Balkontuer_state closed
2020-07-02 10:40:40 e_KinderZimmer_Rolladen_Balkon_UserMode Auto
2020-07-02 10:49:59 e_KinderZimmer_Rolladen_Balkon_pct 100
2020-07-02 10:40:09 e_KinderZimmer_Rolladen_Fenster_UserMode Auto
2020-07-02 10:49:59 e_KinderZimmer_Rolladen_Fenster_pct 100
2020-07-02 11:10:29 e_Temp_outside_temperature 20.5
2020-07-02 11:05:36 mode enabled
2020-07-02 11:05:37 state initialize
2020-07-02 08:24:36 timer_01_c01 03.07.2020 06:15:00|AT
2020-07-02 08:30:00 timer_02_c02 03.07.2020 08:30:00|7
2020-07-02 08:24:36 timer_03_c03 03.07.2020 07:30:00|6
2020-07-02 08:24:36 timer_04_c04 03.07.2020 07:30:00|AT
2020-07-02 08:24:36 timer_05_c05 02.07.2020 22:00:00
2020-07-02 08:24:36 timer_06_c06 02.07.2020 22:00:00
2020-07-02 08:24:36 timer_07_c07 02.07.2020 22:00:00
2020-07-02 08:24:36 timer_08_c08 02.07.2020 22:00:00
2020-07-02 08:24:36 timer_09_c09 02.07.2020 22:00:00
2020-07-02 08:24:36 timer_10_c14 03.07.2020 00:10:00
2020-07-02 08:24:36 timer_11_c15 03.07.2020 00:20:00
2020-07-02 08:24:36 timer_12_c16 03.07.2020 00:30:00
Regex:
accu:
cond:
JasminFrei:
0:
&STATE ^JasminFrei$
12:
&STATE ^JasminFrei$
13:
&STATE ^JasminFrei$
14:
&STATE ^JasminFrei$
15:
&STATE ^JasminFrei$
KinderZimmer_Balkontuer:
0:
1:
10:
11:
12:
13:
14:
15:
2:
3:
4:
state ^KinderZimmer_Balkontuer$:^state:
5:
state ^KinderZimmer_Balkontuer$:^state:
6:
state ^KinderZimmer_Balkontuer$:^state:
7:
state ^KinderZimmer_Balkontuer$:^state:
8:
state ^KinderZimmer_Balkontuer$:^state:
9:
state ^KinderZimmer_Balkontuer$:^state:
KinderZimmer_Rolladen_Balkon:
0:
pct ^KinderZimmer_Rolladen_Balkon$:^pct:
1:
10:
11:
UserMode ^KinderZimmer_Rolladen_Balkon$:^UserMode:
pct ^KinderZimmer_Rolladen_Balkon$:^pct:
12:
pct ^KinderZimmer_Rolladen_Balkon$:^pct:
13:
pct ^KinderZimmer_Rolladen_Balkon$:^pct:
14:
pct ^KinderZimmer_Rolladen_Balkon$:^pct:
15:
pct ^KinderZimmer_Rolladen_Balkon$:^pct:
2:
3:
4:
pct ^KinderZimmer_Rolladen_Balkon$:^pct:
5:
pct ^KinderZimmer_Rolladen_Balkon$:^pct:
6:
7:
pct ^KinderZimmer_Rolladen_Balkon$:^pct:
8:
pct ^KinderZimmer_Rolladen_Balkon$:^pct:
9:
KinderZimmer_Rolladen_Fenster:
0:
1:
10:
UserMode ^KinderZimmer_Rolladen_Fenster$:^UserMode:
pct ^KinderZimmer_Rolladen_Fenster$:^pct:
11:
12:
13:
14:
15:
2:
3:
4:
5:
6:
7:
8:
9:
Temp_outside:
0:
1:
10:
temperature ^Temp_outside$:^temperature:
11:
temperature ^Temp_outside$:^temperature:
12:
13:
14:
15:
2:
3:
4:
5:
6:
7:
8:
9:
di_KinderZimmer_Rolladen:
12:
StartLangsam ^di_KinderZimmer_Rolladen$:^StartLangsam :
13:
StartLangsam | AT ^di_KinderZimmer_Rolladen$:^StartLangsam | AT :
14:
StartLangsam | AT ^di_KinderZimmer_Rolladen$:^StartLangsam | AT :
15:
StartLangsam | AT ^di_KinderZimmer_Rolladen$:^StartLangsam | AT :
9:
Balkon ^di_KinderZimmer_Rolladen$:^Balkon:
wech:
1:
&STATE ^wech$
2:
&STATE ^wech$
3:
&STATE ^wech$
attr:
cmdState:
cmdpause:
120
120
wait:
0:
int(rand(300))
1:
int(rand(600))
2:
int(rand(600))
3:
int(rand(600))
4:
int(rand(600))
5:
int(rand(600))
6:
int(rand(600))
7:
int(rand(600))
8:
int(rand(600))
waitdel:
condition:
0 ::DOIF_time_once($hash,0,$wday,"AT") and ::InternalDoIf($hash,'JasminFrei','STATE') eq "0" and ::isday and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Balkon','pct') < 20
1 ::DOIF_time_once($hash,1,$wday,"7") and ::InternalDoIf($hash,'wech','STATE') eq "wech"
10 ::ReadingValDoIf($hash,'Temp_outside','temperature') > 25 and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Fenster','pct') > 40 and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Fenster','UserMode') ne "manuell"
11 ::ReadingValDoIf($hash,'Temp_outside','temperature') > 25 and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Balkon','pct') > 40 and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Balkon','UserMode') ne "manuell"
12 ::ReadingValDoIf($hash,'di_KinderZimmer_Rolladen','StartLangsam ') and ::InternalDoIf($hash,'JasminFrei','STATE') eq "1" and ::isday and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Balkon','pct') < 25
13 ::ReadingValDoIf($hash,'di_KinderZimmer_Rolladen','StartLangsam | AT ') + ::DOIF_time_once($hash,9,$wday) and ::InternalDoIf($hash,'JasminFrei','STATE') eq "1" and ::isday and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Balkon','pct') < 50
14 ::ReadingValDoIf($hash,'di_KinderZimmer_Rolladen','StartLangsam | AT ') + ::DOIF_time_once($hash,10,$wday) and ::InternalDoIf($hash,'JasminFrei','STATE') eq "1" and ::isday and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Balkon','pct') < 75
15 ::ReadingValDoIf($hash,'di_KinderZimmer_Rolladen','StartLangsam | AT ') + ::DOIF_time_once($hash,11,$wday) and ::InternalDoIf($hash,'JasminFrei','STATE') eq "1" and ::isday and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Balkon','pct') < 100
2 ::DOIF_time_once($hash,2,$wday,"6") and ::InternalDoIf($hash,'wech','STATE') eq "wech"
3 ::DOIF_time_once($hash,3,$wday,"AT") and ::InternalDoIf($hash,'wech','STATE') eq "wech"
4 ::DOIF_time_once($hash,4,$wday) and ::ReadingValDoIf($hash,'KinderZimmer_Balkontuer','state') eq "open" and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Balkon','pct') > 50
5 ::DOIF_time_once($hash,5,$wday) and ::ReadingValDoIf($hash,'KinderZimmer_Balkontuer','state') eq "open" and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Balkon','pct') <= 50
6 ::DOIF_time_once($hash,6,$wday) and ::ReadingValDoIf($hash,'KinderZimmer_Balkontuer','state') eq "closed"
7 ::DOIF_time_once($hash,7,$wday) and ::ReadingValDoIf($hash,'KinderZimmer_Balkontuer','state') eq "tilted" and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Balkon','pct') > 10
8 ::DOIF_time_once($hash,8,$wday) and ::ReadingValDoIf($hash,'KinderZimmer_Balkontuer','state') eq "tilted" and ::ReadingValDoIf($hash,'KinderZimmer_Rolladen_Balkon','pct') <= 10
9 ::ReadingValDoIf($hash,'KinderZimmer_Balkontuer','state') eq "closed" and ::ReadingValDoIf($hash,'di_KinderZimmer_Rolladen','Balkon') eq "soll_zu"
days:
0 AT
1 7
2 6
3 AT
do:
0:
0 set KinderZimmer_Rolladen_Balkon 20
1:
0 set KinderZimmer_Rolladen_Fenster on, set KinderZimmer_Rolladen_Balkon on
10:
0 set KinderZimmer_Rolladen_Fenster 40
11:
0 set KinderZimmer_Rolladen_Balkon 40
12:
0 set KinderZimmer_Rolladen_Balkon 25
13:
0 set KinderZimmer_Rolladen_Balkon 50
14:
0 set KinderZimmer_Rolladen_Balkon 75
15:
0 set KinderZimmer_Rolladen_Balkon 100, set KinderZimmer_Rolladen_Fenster on
16:
2:
0 set KinderZimmer_Rolladen_Fenster on, set KinderZimmer_Rolladen_Balkon on
3:
0 set KinderZimmer_Rolladen_Fenster on, set KinderZimmer_Rolladen_Balkon on
4:
0 set KinderZimmer_Rolladen_Fenster off, set KinderZimmer_Rolladen_Balkon 50, setreading di_KinderZimmer_Rolladen Balkon soll_zu
5:
0 set KinderZimmer_Rolladen_Fenster off
6:
0 set KinderZimmer_Rolladen_Fenster off, set KinderZimmer_Rolladen_Balkon off
7:
0 set KinderZimmer_Rolladen_Fenster off, set KinderZimmer_Rolladen_Balkon 10, setreading di_KinderZimmer_Rolladen Balkon soll_zu
8:
0 set KinderZimmer_Rolladen_Fenster off, set KinderZimmer_Rolladen_Balkon off
9:
0 set KinderZimmer_Rolladen_Balkon off, setreading di_KinderZimmer_Rolladen Balkon zu
helper:
DEVFILTER ^global$|^KinderZimmer_Rolladen_Fenster$|^wech$|^KinderZimmer_Rolladen_Balkon$|^Temp_outside$|^JasminFrei$|^di_KinderZimmer_Rolladen$|^KinderZimmer_Balkontuer$
NOTIFYDEV global|KinderZimmer_Rolladen_Fenster|wech|KinderZimmer_Rolladen_Balkon|Temp_outside|JasminFrei|di_KinderZimmer_Rolladen|KinderZimmer_Balkontuer
event battery: ok,humidity: 72,T: 20.5 H: 72,temperature: 20.5,DiffNordOstBlack: 12.3,DiffNordOstWhite: 8.1
globalinit 1
last_timer 12
sleeptimer -1
triggerDev Temp_outside
triggerEvents:
battery: ok
humidity: 72
T: 20.5 H: 72
temperature: 20.5
DiffNordOstBlack: 12.3
DiffNordOstWhite: 8.1
triggerEventsState:
battery: ok
humidity: 72
state: T: 20.5 H: 72
temperature: 20.5
DiffNordOstBlack: 12.3
DiffNordOstWhite: 8.1
internals:
all JasminFrei:STATE wech:STATE
interval:
intervalfunc:
localtime:
0 1593749700
1 1593757800
10 1593728400
11 1593729000
2 1593754200
3 1593754200
4 1593720000
5 1593720000
6 1593720000
7 1593720000
8 1593720000
9 1593727800
readings:
all KinderZimmer_Rolladen_Balkon:pct KinderZimmer_Balkontuer:state di_KinderZimmer_Rolladen:Balkon Temp_outside:temperature KinderZimmer_Rolladen_Fenster:pct KinderZimmer_Rolladen_Fenster:UserMode KinderZimmer_Rolladen_Balkon:UserMode di_KinderZimmer_Rolladen:StartLangsam
realtime:
0 06:15:00
1 08:30:00
10 00:20:00
11 00:30:00
2 07:30:00
3 07:30:00
4 22:00:00
5 22:00:00
6 22:00:00
7 22:00:00
8 22:00:00
9 00:10:00
time:
0 06:15:00
1 ({sunrise(0,"08:30","9:00")})
10 00:20:00
11 00:30:00
2 ({sunrise(0,"07:30","9:00")})
3 ({sunrise(0,"07:30","9:00")})
4 ({sunset(-600,"16:00","22:00")})
5 ({sunset(-600,"16:00","22:00")})
6 ({sunset(-600,"16:00","22:00")})
7 ({sunset(-600,"16:00","22:00")})
8 ({sunset(-600,"16:00","22:00")})
9 00:10:00
timeCond:
0 0
1 1
10 14
11 15
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 13
timer:
0 0
1 0
10 0
11 0
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
timers:
0 0
1 1
13 9
14 10
15 11
2 2
3 3
4 4
5 5
6 6
7 7
8 8
trigger:
triggertime:
1593720000:
localtime 1593720000
hash:
1593727800:
localtime 1593727800
hash:
1593728400:
localtime 1593728400
hash:
1593729000:
localtime 1593729000
hash:
1593749700:
localtime 1593749700
hash:
1593754200:
localtime 1593754200
hash:
1593757800:
localtime 1593757800
hash:
uiState:
uiTable:
Attributes:
cmdpause ::::::::::120:120
do always
room 99_System
timerWithWait 1
wait int(rand(300)):int(rand(600)):int(rand(600)):int(rand(600)):int(rand(600)):int(rand(600)):int(rand(600)):int(rand(600)):int(rand(600))
Was mache ich hier falsch?
Danke
Stefan
Update:
Ich konnte das Problem lösen. Die Klammern waren falsch:
HIer ein richtiger Eintrag:
DOELSEIF ([([di_KinderZimmer_Rolladen:StartLangsam]+[00:10]) | AT] and [JasminFrei] eq "1" and ::isday and [KinderZimmer_Rolladen_Balkon:pct] < 50)
Gruß
Stefan
Hallo Zusammen,
kann mir ein das Phänomen erklären warum bei meinem DOIF mit relativem Zeitintervall und einer zusätzlichen Bedingung, immer ein Event generiert wird, obwohl keine Bedingung erfüllt ist (Ausser der Zeit natürlich).
([KNX_2_Hue_Wonhzimmertisch_2] eq "9" and [+1]) (set HUEGroup1 dimDown) DOELSEIF ([KNX_2_Hue_Wonhzimmertisch_2] eq "1" and [+1]) (set HUEGroup1 dimUp) DOELSE
2022-05-26 09:10:19 DOIF livingdim2hue cmd_event: timer_2
2022-05-26 09:10:19 DOIF livingdim2hue cmd_3
2022-05-26 09:10:20 DOIF livingdim2hue cmd_nr: 3
2022-05-26 09:10:20 DOIF livingdim2hue cmd: 3
2022-05-26 09:10:20 DOIF livingdim2hue cmd_event: timer_2
2022-05-26 09:10:20 DOIF livingdim2hue cmd_3
2022-05-26 09:10:21 DOIF livingdim2hue cmd_nr: 3
2022-05-26 09:10:21 DOIF livingdim2hue cmd: 3
2022-05-26 09:10:21 DOIF livingdim2hue cmd_event: timer_2
2022-05-26 09:10:21 DOIF livingdim2hue cmd_3
2022-05-26 09:10:22 DOIF livingdim2hue cmd_nr: 3
2022-05-26 09:10:22 DOIF livingdim2hue cmd: 3
2022-05-26 09:10:22 DOIF livingdim2hue cmd_event: timer_2
2022-05-26 09:10:22 DOIF livingdim2hue cmd_3
2022-05-26 09:10:23 DOIF livingdim2hue cmd_nr: 3
Zweite Frage, kann ich die Zeit noch unter eine Sekunde bekommen? Ich hätte da an eine halbe Sekunde gedacht. aber "0.5" wird nicht akzeptiert.?
Gruß
Rubinho
--Update--
Habe das letzte DOELSE weggelassen, jetzt hab ich kein Event mehr. Verstehen tue ich es trotzdem nicht.
Zweite Frage ist noch aktiv :D
Zitat von: rubinho am 26 Mai 2022, 09:13:21
Hallo Zusammen,
kann mir ein das Phänomen erklären warum bei meinem DOIF mit relativem Zeitintervall und einer zusätzlichen Bedingung, immer ein Event generiert wird, obwohl keine Bedingung erfüllt ist (Ausser der Zeit natürlich).
([KNX_2_Hue_Wonhzimmertisch_2] eq "9" and [+1]) (set HUEGroup1 dimDown) DOELSEIF ([KNX_2_Hue_Wonhzimmertisch_2] eq "1" and [+1]) (set HUEGroup1 dimUp) DOELSE
2022-05-26 09:10:19 DOIF livingdim2hue cmd_event: timer_2
2022-05-26 09:10:19 DOIF livingdim2hue cmd_3
2022-05-26 09:10:20 DOIF livingdim2hue cmd_nr: 3
2022-05-26 09:10:20 DOIF livingdim2hue cmd: 3
2022-05-26 09:10:20 DOIF livingdim2hue cmd_event: timer_2
2022-05-26 09:10:20 DOIF livingdim2hue cmd_3
2022-05-26 09:10:21 DOIF livingdim2hue cmd_nr: 3
2022-05-26 09:10:21 DOIF livingdim2hue cmd: 3
2022-05-26 09:10:21 DOIF livingdim2hue cmd_event: timer_2
2022-05-26 09:10:21 DOIF livingdim2hue cmd_3
2022-05-26 09:10:22 DOIF livingdim2hue cmd_nr: 3
2022-05-26 09:10:22 DOIF livingdim2hue cmd: 3
2022-05-26 09:10:22 DOIF livingdim2hue cmd_event: timer_2
2022-05-26 09:10:22 DOIF livingdim2hue cmd_3
2022-05-26 09:10:23 DOIF livingdim2hue cmd_nr: 3
Zweite Frage, kann ich die Zeit noch unter eine Sekunde bekommen? Ich hätte da an eine halbe Sekunde gedacht. aber "0.5" wird nicht akzeptiert.?
Gruß
Rubinho
--Update--
Habe das letzte DOELSE weggelassen, jetzt hab ich kein Event mehr. Verstehen tue ich es trotzdem nicht.
Zweite Frage ist noch aktiv :D
Deine Definition ist so nicht sinnvoll und ressourcenintensiv, die sekündliche Abfrage kannst du weglassen, denn die Bedingung wird getriggert, wenn KNX_2_Hue_Wonhzimmertisch_2 sich ändert und ein Event erzeugt. Damit erledigt sich auch die zweite Frage - unter einer Sekunde ist nicht vorgesehen.
Zitat von: Damian am 26 Mai 2022, 11:53:16
Deine Definition ist so nicht sinnvoll und ressourcenintensiv, die sekündliche Abfrage kannst du weglassen, denn die Bedingung wird getriggert, wenn KNX_2_Hue_Wonhzimmertisch_2 sich ändert und ein Event erzeugt. Damit erledigt sich auch die zweite Frage - unter einer Sekunde ist nicht vorgesehen.
Wenn mir jemand eine bessere Lösung anbietet, wie ich meine Hue Lampe an einem KNX Schalter gedimmt bekomme, nehme ich die Lösung gerne.
Ich hab neben dieser Lösung noch eine recht zusammengebastelte Schleife unter 99_myUtils gescriptet, mit der ich allerdings nicht zufrieden bin.
Mein KNX Schalter hat die Zustände 1, 9 und die Grundstellung 0. Da pulst allerdings nichts. Der Wert steht einfach nur an. Und unter Hue gibt es meines Wissens keine Option die aus diesen Zuständen kontinuierlich hoch, oder runter dimmt.
Zitat von: rubinho am 26 Mai 2022, 18:52:25
Wenn mir jemand eine bessere Lösung anbietet, wie ich meine Hue Lampe an einem KNX Schalter gedimmt bekomme, nehme ich die Lösung gerne.
Ich hab neben dieser Lösung noch eine recht zusammengebastelte Schleife unter 99_myUtils gescriptet, mit der ich allerdings nicht zufrieden bin.
Mein KNX Schalter hat die Zustände 1, 9 und die Grundstellung 0. Da pulst allerdings nichts. Der Wert steht einfach nur an. Und unter Hue gibt es meines Wissens keine Option die aus diesen Zuständen kontinuierlich hoch, oder runter dimmt.
Die einzige Frage, die du dir beantworten musst ist: Liefert dein KNX-Schalter ein Event (siehe Event-Monitor) wenn er seinen Zustand ändert?
Zitat von: Damian am 26 Mai 2022, 19:03:50
Die einzige Frage, die du dir beantworten musst ist: Liefert dein KNX-Schalter ein Event (siehe Event-Monitor) wenn er seinen Zustand ändert?
Na klar liefert der KNX Schalter ein Event. Solange ich die eine Taste drücke, den Wert 1, die andere Taste den Wert 9. Wenn kein Taste betätigt wird, steht der Wert 0 an und jedes mal wird ein Event generiert.
Das Problem ist doch aber ein anderes. Ich will ja nicht den Taster 20 mal betätigen bis er auf 5% gedimmt ist, sondern die Taste drücken und halten.
Ein internes Modul in Fhem muss für mich dann das Pulsieren des Events übernehmen. Deswegen der Sekundentakt.
Gruß
Rubinho
Zitat von: rubinho am 26 Mai 2022, 22:02:46
Na klar liefert der KNX Schalter ein Event. Solange ich die eine Taste drücke, den Wert 1, die andere Taste den Wert 9. Wenn kein Taste betätigt wird, steht der Wert 0 an und jedes mal wird ein Event generiert.
Das Problem ist doch aber ein anderes. Ich will ja nicht den Taster 20 mal betätigen bis er auf 5% gedimmt ist, sondern die Taste drücken und halten.
Ein internes Modul in Fhem muss für mich dann das Pulsieren des Events übernehmen. Deswegen der Sekundentakt.
Gruß
Rubinho
Dann solltest du dir eine andere Lösung überlegen. Du willst ja nicht 24/7 dein FHEM sekündlich triggern, damit du einmal am Tag etwas dimmen kannst.
Wenn du öfters so die Probleme löst, dann wird sich dein FHEM irgendwann mit sich selbst beschäftigen.
Der Lösungsansatz sollte anders sein:
Du reagierst auf den entsprechenden Wert und fängst erst dann an im Sekundentakt zu dimmen, solange die Taste gedrückt ist. Das kannst du auch mit DOIF machen. Allerdings bietet sich dafür der Perl-Modus mit der set_Exec-Funktion an, siehe: https://wiki.fhem.de/wiki/DOIF/Perl-Modus#Timer_setzen:_set_Exec.28.29
Alles klar, danke für die Info.
Es war jedenfalls ein Versuch wert. Allerdings skaliert dieser Lösungsansatz, wie du schon geschrieben hast nicht und von daher muss ich weiter Ausschau halten.
Ich suche nach einem Lösungsansatz ohne großartiges Scripting. Ich habe die Erfahrung gemacht, dass ich immer mal Monate habe (meistens die hellen Monate), wo Fhem einfach nur seine Arbeit verrichtet und ich keinen Gedanken daran verschwende. Wenn ich dann mal auf so ein Script stoße, dass ich vor Monaten mal verstanden habe und muss anpassungen daran durchführen, wirds immer kompliziert und ich muss das Rad immer wieder neu erfinden. Von daher verfolge ich immer mehr die Philosophie "keeping it simple". Einfache Lösungen, die auch nach einem Jahr ohne weiteres nachvollziehbar sind. Ein Hilfsmodul das pulst wäre so ein Ansatz.
Wie schon geschrieben, ich habe ja bereits ein Script. Aber mir wäre eine einfachere Lösung lieber.
Trotzdem danke.
Gruß
Rubinho
Wenn du "HUE dimmen" in der Forumsuche eingibst, dann findest du unzählige Beiträge zu dem Thema - auch welche mit DOIF.
Hallo,
Ich habe mir ein DOIf erstellt welches zwei Werte voneinander abzieht.
Ich will dieses jede 5 Sekunden aktualisieren. Leider macht das doif das ganze nur einmal anc läuft zwar der Timer aber keine neue Berechnung findet statt und auch das Reading wird nicht neu geschrieben.
Hat jemand eine Idee?
defmod doif_aktuellerverbauch DOIF ([+5]) (setreading PV_ModuleGesamt aktuellerverbrauch {([TibberPulse:power:d0]-[TibberPulse:powerProduction:d0])})
attr doif_
Du musst das do always-Attribut setzen.
Warum lässt du das aller 5 min machen?