Hallo DOIF-Nutzer,
eine wichtige Funktionalität fehlte bisher im Modul, nämlich wiederholende Ausführungen durch Selbsttriggerung. Dieses Feature wurde nun eingebaut.
Es gibt jetzt ein neues Attribut namens repeatcmd. Wie beim wait-Attribut können pro DO-Fall Sekundenangaben getrennt mit Doppelpunkt angegeben werden.
Syntax: attr <Modulname> repeatcmd <Sekunden für Befehlsfolge des ersten DO-Falls>:<Sekunden für Befehlsfolge des zweiten DO-Falls>:...
Beispiel
define di_push DOIF ([Frost] eq "on")(push Frostmeldung)
attr di_push repeatcmd 3600
Hier wird beim Eintreffen des Ereignisses die push-Meldung stündlich wiederholt, bis Frost ungleich "on" ist.
Die Anzahl der Wiederholungen lässt sich mit dem Attribut repeatsame begrenzen.
Durch
attr di_push repeatsame 3
wird die stündliche Wiederholung bis zu drei mal ausgeführt.
Ebenso lässt sich das neue Attribut mit Zeitangaben kombinieren. Beispiel:
define di DOIF ([08:00])(push Täglich grüßt das Murmeltier)
attr di repeatcmd 300
attr di repeatsame 10
attr di do always
Hier alle 5 Minuten insgesamt 10 mal.
Ebenso sind indirekte Zeitangaben wie bei wait möglich:
attr di_test repeatcmd [dummy_t]:my_function():...
Anwendungsbeispiel: Anwesenheitssimulation
define di_presence_simulation DOIF ([19:00-00:00])(set lamp on-for-timer {(int(rand(1800)+300))}) DOELSE
attr di_presence_simulation repeatcmd rand(3600)+1800
attr di_presence_simulation do always
Das neue Attribut lässt sich mit allen anderen Attributen des Moduls kombinieren.
Die Sekundenangaben müssen größer Null sein.
Testversion befindet sich im Anhang.
Edit: Diese Version wurde eingecheckt.
Gruß
Damian
Oh, das klingt nach einem echten Problemlöser für offene Fenster, Türen, fertigen Waschmaschinen und Wäschetrocknern :)
Zitat von: Rince am 07 November 2015, 12:31:42
Oh, das klingt nach einem echten Problemlöser für offene Fenster, Türen, fertigen Waschmaschinen und Wäschetrocknern :)
ja, insbesondere bei nicht zyklischen sendenden Sensoren. Man konnte zwar über relative Zeitangaben (z. B. [+00:01]) in der Definition das Modul immer wieder antriggern, allerdings wurde dann das Modul unnötig ständig getriggert.
Ich habe im ersten Post noch ein Beispiel für Anwendungssimulation in Kombination mit Zeitintervallen angegeben.
Gruß
Damian
Klasse, wieder mehr Möglichkeiten...
Allerdings verstehe ich in dem Beispiel
define di DOIF ([08:00])(push Täglich grüßt das Murmeltier)
attr di repeatcmd 300
attr di repeatsame 10
attr di do always
das Attribut do always nicht.
Mein Verständnis: durch repeatcmd wird alle 5 Min wiederholt (das ist doch implizit der do always), durch repeatsame erfolgt allerdings eine Begrenzung auf 10 mal.
In den Beispielen zuvor wurde für Wiederholungen ja auch kein do always benötigt.
LG
Holger
Zitat von: Omega am 09 November 2015, 10:43:55
Klasse, wieder mehr Möglichkeiten...
Allerdings verstehe ich in dem Beispiel
define di DOIF ([08:00])(push Täglich grüßt das Murmeltier)
attr di repeatcmd 300
attr di repeatsame 10
attr di do always
das Attribut do always nicht.
Mein Verständnis: durch repeatcmd wird alle 5 Min wiederholt (das ist doch implizit der do always), durch repeatsame erfolgt allerdings eine Begrenzung auf 10 mal.
In den Beispielen zuvor wurde für Wiederholungen ja auch kein do always benötigt.
LG
Holger
ja, in Verbindung mit dem neuen Attribut repeatcmd, bezieht sich repeatsame auf die Anzahl der automatischen Wiederholungen. Damit auch morgen um 8:00 Uhr alles funktioniert muss noch das do always dazu.
Gruß
Damian
Hallo Damian,
ist es möglich bei DOIF die so aufgebaut sind (Bedingung1) (Kommandos1) (Kommandos2) zb. nur cmd2 zu wiederholen wie bei Wait-Attribut?
Gruß
Claudiu
Zitat von: sentinel1 am 09 November 2015, 18:09:03
Hallo Damian,
ist es möglich bei DOIF die so aufgebaut sind (Bedingung1) (Kommandos1) (Kommandos2) zb. nur cmd2 zu wiederholen wie bei Wait-Attribut?
Gruß
Claudiu
Nein. Z. Zt. kann man nur den kompletten DO-Fall wiederholen lassen.
Gruß
Damian
Hi Damian,
das Feature funktioniert wunderbar! :D
Besten Dank - darauf habe ich gewartet!
BG,
Max
Da es bisher keine Fehlermeldungen zu dieser Version gibt, werde ich sie in den nächsten Tagen einchecken.
Gruß
Damian
Zitat von: Damian am 13 November 2015, 21:22:37
Da es bisher keine Fehlermeldungen zu dieser Version gibt, werde ich sie in den nächsten Tagen einchecken.
Diese Version wurde eingecheckt und ist ab morgen per Update verfügbar.
Gruß
Damian
Hallo Damian,
Zitat von: Damian am 09 November 2015, 18:28:54
Nein. Z. Zt. kann man nur den kompletten DO-Fall wiederholen lassen.
Ich könnte mir für teilweise Wdh. Anwendungsszenarien vorstellen.
Vielleicht hast du ja irgendwann mal Zeit, das noch einzubauen in ein zukünftiges Update :-)
Viele Grüße,
Heiko
Könnte man ein DOIF nicht auch als eine Art Zufallstimer oder Urlaubsschaltung benutzen, so in der Art ich sage mal ich möchte das er
1. in der Zeit von-bis immer an ist - das geht ja sowieso
2. in der Zeit von-bis immer mal wieder Aus/Ein schaltet
3. in der Zeit von-bis zufällig mal Ein schaltet
Hallo moonsorrox,
Zitat von: moonsorrox am 12 Januar 2016, 19:34:36
Könnte man ein DOIF nicht auch als eine Art Zufallstimer oder Urlaubsschaltung benutzen, so in der Art ich sage mal ich möchte das er
2. in der Zeit von-bis immer mal wieder Aus/Ein schaltet
3. in der Zeit von-bis zufällig mal Ein schaltet
Ist das nicht was Damian im Start-Beitrag in diesem Thread als Beispiel aufführt oder meinst du etwas anderes?
Zitat
Anwendungsbeispiel: Anwesenheitssimulation
define di_presence_simulation DOIF ([19:00-00:00])(set lamp on-for-timer {(int(rand(1800)+300))}) DOELSE
attr di_presence_simulation repeatcmd rand(3600)+1800
attr di_presence_simulation do always
Viele Grüße,
Heiko
Hab ich jetzt gar nicht drauf geachtet..! :-\
Aber ja ist ja etwas ähnliches...! Muss mich mal mit beschäftigen oder eben mal nachstellen...
ich habe nochmal eine Frage zu dem Anwendungsbeispiel: Anwesenheitssimulation
Ich habe das mal Testweise nach gestellt um zu sehen wie es funktioniert, aber so ganz ist mir das nicht klar
Hier mal das list:
Internals:
CFGFN ./FHEM/Test.cfg
DEF ([19:00-00:45])(set Dachlicht_03 on-for-timer {(int(rand(1800)+300))}) DOELSE
NAME di_presence_simulation
NR 3688
NTFY_ORDER 50-di_presence_simulation
STATE cmd_2
TYPE DOIF
Readings:
2016-01-19 23:54:11 Event wait_timer: no timer
2016-01-20 00:45:00 cmd_event timer_2
2016-01-20 00:45:00 cmd_nr 2
2016-01-20 00:45:00 state cmd_2
2016-01-19 19:00:00 timer_1_c1 20.01.2016 19:00:00
2016-01-20 00:45:00 timer_2_c1 21.01.2016 00:45:00
2016-01-20 00:45:00 wait_timer no timer
Condition:
0 DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"")
Days:
Devices:
Do:
0:
0 set Dachlicht_03 on-for-timer {(int(rand(1800)+300))}
1:
0
Helper:
event batVoltage: 3.03
globalinit 1
last_timer 2
sleepdevice timer_1
sleepsubtimer 0
sleeptimer -1
triggerDev Temperatur_Bad
triggerEvents:
batVoltage: 3.03
battery: ok
humidity: 31
luminosity: 6.93
T: 20.1 H: 31 L: 6.93
temperature: 20.1
Internals:
Itimer:
Readings:
Realtime:
0 19:00:00
1 00:45:00
Regexp:
State:
Time:
0 19:00:00
1 00:45:00
Timecond:
0 0
1 0
Timer:
0 0
1 0
Timerfunc:
Timers:
0 0 1
Attributes:
alias Anwesenheitssimulation Licht EG
do always
group Anwesenheitssimulation
icon light_on-for-timer@#F0E68C
repeatcmd rand(3600)+1800
room AutomationTest
wenn ich jetzt in mein Log schaue sehe ich folgende Ereignisse die ich nicht verstehe.
Die Angebane hinter "on-for-timer" sind ja die Sekunden, dass bedeutet doch das solange das Dachlicht eingeschaltet ist.
Wenn ich jetzt mal 21:09:32 nehme bleibt das Licht für 1691sec. eingeschaltet dass sind ca. 28:18 min. das heißt das Licht ist eigentlich bis 22:37 Uhr eingeschaltet, aber da kommt doch vorher schon die nächste Zeit 21:47:57 Uhr und setzt erneut den on-for-timer auf 529sec. das heißt die Beleuchtung ist doch gar nicht ausgegangen...! oder verstehe ich das falsch..?
hier mal die Logeinträge
2016.01.19 22:57:09 3: CUL_HM set Dachlicht_03 on-for-timer 1703
2016.01.19 22:18:54 3: CUL_HM set Dachlicht_03 on-for-timer 899
2016.01.19 21:47:57 3: CUL_HM set Dachlicht_03 on-for-timer 529
2016.01.19 21:09:32 3: CUL_HM set Dachlicht_03 on-for-timer 1691
2016.01.19 20:06:45 3: CUL_HM set Dachlicht_03 on-for-timer 1014
2016.01.19 19:00:00 3: CUL_HM set Dachlicht_03 on-for-timer 1125
Zitat von: moonsorrox am 20 Januar 2016, 13:44:46
ich habe nochmal eine Frage zu dem Anwendungsbeispiel: Anwesenheitssimulation
Ich habe das mal Testweise nach gestellt um zu sehen wie es funktioniert, aber so ganz ist mir das nicht klar
Hier mal das list:
Internals:
CFGFN ./FHEM/Test.cfg
DEF ([19:00-00:45])(set Dachlicht_03 on-for-timer {(int(rand(1800)+300))}) DOELSE
NAME di_presence_simulation
NR 3688
NTFY_ORDER 50-di_presence_simulation
STATE cmd_2
TYPE DOIF
Readings:
2016-01-19 23:54:11 Event wait_timer: no timer
2016-01-20 00:45:00 cmd_event timer_2
2016-01-20 00:45:00 cmd_nr 2
2016-01-20 00:45:00 state cmd_2
2016-01-19 19:00:00 timer_1_c1 20.01.2016 19:00:00
2016-01-20 00:45:00 timer_2_c1 21.01.2016 00:45:00
2016-01-20 00:45:00 wait_timer no timer
Condition:
0 DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"")
Days:
Devices:
Do:
0:
0 set Dachlicht_03 on-for-timer {(int(rand(1800)+300))}
1:
0
Helper:
event batVoltage: 3.03
globalinit 1
last_timer 2
sleepdevice timer_1
sleepsubtimer 0
sleeptimer -1
triggerDev Temperatur_Bad
triggerEvents:
batVoltage: 3.03
battery: ok
humidity: 31
luminosity: 6.93
T: 20.1 H: 31 L: 6.93
temperature: 20.1
Internals:
Itimer:
Readings:
Realtime:
0 19:00:00
1 00:45:00
Regexp:
State:
Time:
0 19:00:00
1 00:45:00
Timecond:
0 0
1 0
Timer:
0 0
1 0
Timerfunc:
Timers:
0 0 1
Attributes:
alias Anwesenheitssimulation Licht EG
do always
group Anwesenheitssimulation
icon light_on-for-timer@#F0E68C
repeatcmd rand(3600)+1800
room AutomationTest
wenn ich jetzt in mein Log schaue sehe ich folgende Ereignisse die ich nicht verstehe.
Die Angebane hinter "on-for-timer" sind ja die Sekunden, dass bedeutet doch das solange das Dachlicht eingeschaltet ist.
Wenn ich jetzt mal 21:09:32 nehme bleibt das Licht für 1691sec. eingeschaltet dass sind ca. 28:18 min. das heißt das Licht ist eigentlich bis 22:37 Uhr eingeschaltet, aber da kommt doch vorher schon die nächste Zeit 21:47:57 Uhr und setzt erneut den on-for-timer auf 529sec. das heißt die Beleuchtung ist doch gar nicht ausgegangen...! oder verstehe ich das falsch..?
hier mal die Logeinträge
2016.01.19 22:57:09 3: CUL_HM set Dachlicht_03 on-for-timer 1703
2016.01.19 22:18:54 3: CUL_HM set Dachlicht_03 on-for-timer 899
2016.01.19 21:47:57 3: CUL_HM set Dachlicht_03 on-for-timer 529
2016.01.19 21:09:32 3: CUL_HM set Dachlicht_03 on-for-timer 1691
2016.01.19 20:06:45 3: CUL_HM set Dachlicht_03 on-for-timer 1014
2016.01.19 19:00:00 3: CUL_HM set Dachlicht_03 on-for-timer 1125
In dem Fall geht sie wohl nicht aus. Wenn deine Lampe auf jeden Fall ausgehen soll, dann musst du den festen Wiederholungsanteil höher setzen z. B.
repeatcmd rand(3600)+2600
Da rand(3600)+2600 immer größer ist, als die on-for-time-Zeit von rand(1800)+300 muss die Lampe vorher ausgehen, bevor sie wieder angeht.
Gruß
Damian
Hallo,
ich möchte eine Nachricht, wenn das Fenster länger als 20 sec. offen ist und nach weiteren 20 sec. die gleiche Nachricht noch einmal.
Mit meinem DOIF bekomme ich es nicht gebacken.
Das sendet auch, wenn das Fenster vor den 20 sec. wieder geschlossen wird und auch wenn sich der Status von HandyDieter von "off" auf "on" ändert.
Ich habe schon so ziemlich alle Konstellationen aus der commandref probiert. Wo liegt mein Fehler?
define Status_Fenster_WC DOIF ([Fenster_WC] eq "open" and [HandyDieter] eq "on") (set Pushbullet_D message Das Fenster im WC ist noch offen
attr repeatcmd 20
attr repeatsame 2
attr wait 20
Danke schon mal für die Hilfe.
Zitat von: Damian am 20 Januar 2016, 17:16:13
In dem Fall geht sie wohl nicht aus. Wenn deine Lampe auf jeden Fall ausgehen soll, dann musst du den festen Wiederholungsanteil höher setzen z. B.
repeatcmd rand(3600)+2600
Da rand(3600)+2600 immer größer ist, als die on-for-time-Zeit von rand(1800)+300 muss die Lampe vorher ausgehen, bevor sie wieder angeht.
Gruß
Damian
OK, dass werde ich dann mal ausprobieren.
Ich habe jetzt erst einmal alle so gelassen und ein weitere Anwesenheitssimulation erstellt und bekomme bei der einen Fehler angezeigt, währen dessen die andere Simulation läuft. Beide sind identisch nur der zu schaltende Ausgang ist ein anderer.
Aber wo liegt der Fehler jetzt..?
Fehler im DOIF:
2016.01.20 18:15:00 2: di_TerrassenBeleuchtung_simulation: set NI3_LichtTerrasse on-for-timer 509: Unknown argument on-for-timer, choose one of ON OFF TRIGGERList des DOIF:
Internals:
CFGFN ./FHEM/AussenBeleuchtung.cfg
DEF ([18 NI3_LichtTerrasse on-for-timer {(int(rand(1800)+300))}) DOELSE
NAME di_TerrassenBeleuchtung_simulation
NR 988
NTFY_ORDER 50-di_TerrassenBeleuchtung_simulation
STATE Ein
TYPE DOIF
Readings:
2016-01-20 18 Event Next: 18
2016-01-20 18 cmd_event timer_1
2016-01-20 18 cmd_nr 1
2016-01-20 18 error set NI3_LichtTerrasse on-for-timer 509: Unknown argument on-for-timer, choose one of ON OFF TRIGGER
2016-01-20 18 state Ein
2016-01-20 18 timer_1_c1 21.01.2016 18
2016-01-20 18 timer_2_c1 21.01.2016 00
2016-01-20 18 wait_timer 20.01.2016 19 cmd_1 timer_1
Condition:
0 DOIF_time($hash,$hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,"")
Days:
Devices:
Do:
0:
0 set NI3_LichtTerrasse on-for-timer {(int(rand(1800)+300))}
1:
0
Helper:
event loadLvl: low
globalinit 1
last_timer 2
sleepdevice timer_1
sleepsubtimer 0
sleeptimer 0
triggerDev HMUSB
triggerEvents:
loadLvl: low
Internals:
Itimer:
Readings:
Realtime:
0 18
1 00
Regexp:
State:
Time:
0 18
1 00
Timecond:
0 0
1 0
Timer:
0 0
1 0
Timerfunc:
Timers:
0 0 1
Attributes:
alias Anwesenheitssimulation Licht Terrasse
cmdState Ein|Aus
do always
group Anwesenheitssimulation
icon light_on-for-timer@blue
repeatcmd rand(3600)+1800
room AußenLicht EDITH:// ich denke die Probleme kommen deshalb weil mein Netzwerkeingang NI3 nicht mit dem on-for-timer umgehen kann...!
Ich müsste da wohl einen Umweg gehen und die Zeit des DOIF on-for-timer in ein Dummy schreiben und dieses sollte dann den Status weiter geben.
Ich habe mal nur den on-for-timer auf den NI3 mit set set NI3_LichtTerrasse 10 gegeben da bekomme ich den gleichen Fehler wie oben angegeben.
Zitat von: dk3572 am 20 Januar 2016, 17:23:17
Hallo,
ich möchte eine Nachricht, wenn das Fenster länger als 20 sec. offen ist und nach weiteren 20 sec. die gleiche Nachricht noch einmal.
Mit meinem DOIF bekomme ich es nicht gebacken.
Das sendet auch, wenn das Fenster vor den 20 sec. wieder geschlossen wird und auch wenn sich der Status von HandyDieter von "off" auf "on" ändert.
Ich habe schon so ziemlich alle Konstellationen aus der commandref probiert. Wo liegt mein Fehler?
define Status_Fenster_WC DOIF ([Fenster_WC] eq "open" and [HandyDieter] eq "on") (set Pushbullet_D message Das Fenster im WC ist noch offen
attr repeatcmd 20
attr repeatsame 2
attr wait 20
Danke schon mal für die Hilfe.
Du könntest DOELSE verwenden und die rechte Klammer schliessen.
Das ist nur ein Teil der massage, die rechte Klammer ist natürlich geschlossen ;-)
Was meinst du mit dem DOELSE? Wie soll ich das verwenden?
ZitatWas meinst du mit dem DOELSE?
Das Schlüsselwort DOELSE als möglicher Bestandteil der DOIF Definition.
ZitatWie soll ich das verwenden?
Die Frage irritiert mich etwas.
ZitatIch habe schon so ziemlich alle Konstellationen aus der commandref probiert.
Schau Dir doch diesen Abschnitt bitte noch einmal an http://fhem.de/commandref_DE.html#DOIF_Lesbarkeit_der_Definitionen bis zum Abschnitt "Teilausdrücke abfragen" ;) Kommst Du damit klar?
Ich bin dankbar für die Unterstützung und die Hilfestellungen.
Ich lese Anleitungen und Forenbeiträge, probiere die verschiedensten Konstellationen und lerne dadurch immer mehr dazu.
Auch jetzt habe ich mir den Artikel zum wiederholten male durchgelesen. Doch leider will es mir nicht gelingen.
Wäre es nicht weniger zeit intensiv und zielführender wenn ich ein Beispiel gezeigt bekomme, auf dem ich dann weiter aufbauen und dazulernen kann?
ZitatWäre es nicht weniger zeit intensiv und zielführender wenn ich ein Beispiel gezeigt bekomme
Scheinbar nicht, denn die erste beispielhafte Definition in dem verlinkten Abschitt ist das gewünschte Beispiel mit Erläuterungen. Hast Du dazu noch konkrete Fragen?
würde es gehen das DOIF so umzustellen das ich in meinem Fall nicht den on-for-timer nutze sondern eben den set NI3_LichtTerrasse on aber die Simulation trotzdem läuft.
Ich habe da einige Versuche hinter mir aber es gelingt mir nicht :-\
@Ellert
Ok, das war das mit dem Wald und den vielen Bäumen :-[
Scheint jetzt zu funktionieren.
Danke!!!
Zitat von: moonsorrox am 20 Januar 2016, 21:08:49
würde es gehen das DOIF so umzustellen das ich in meinem Fall nicht den on-for-timer nutze sondern eben den set NI3_LichtTerrasse on aber die Simulation trotzdem läuft.
Ich habe da einige Versuche hinter mir aber es gelingt mir nicht :-\
Im Prinzip geht es so:
([<Zeitspanne>]) (<Einschaltbefehl>) (<Ausschaltbefehl>)
wait <Zufallszeitdauer1>, <Zufallszeitdauer2>
repeatcmd <maximale Zufallszeitdauer1 plus maximale Zufallszeitdauer2>
timerWithWait
do always
OK, ich werde mal schauen wie ich das bei mir einbaue...
Ich habe den letzten Versuch von gestern Abend bisher heute noch nicht getestet - der sieht momentan so aus, ich glaube aber das er hiermit nicht ausgeht...!
Evtl. kannst du mal drüber schauen..?
Die Zeiten habe ich bisher noch so gelassen, wenn das Teil erst einmal funktioniert passe ich diese noch an.. jetzt schaue ich erst deinen Vorschlag an.
define di_TerrassenBeleuchtung_Simulation DOIF ([?du_Modus_TerrassenBeleuchtung] eq "Zufall" and ([[du_Anfang_Zufall]])) ({(int(rand(1800)+300))}) (set NI3_LichtTerrasse on) DOELSEIF ([[du_Ende_Zufall]]) (set NI3_LichtTerrasse off)\
attr di_TerrassenBeleuchtung_Simulation alias Anwesenheitssimulation Licht Terrasse
attr di_TerrassenBeleuchtung_Simulation cmdState EIN|AUS
attr di_TerrassenBeleuchtung_Simulation do always
attr di_TerrassenBeleuchtung_Simulation group Anwesenheitssimulation Terrasse
attr di_TerrassenBeleuchtung_Simulation icon light_on-for-timer@blue
attr di_TerrassenBeleuchtung_Simulation repeatcmd rand(3600)+1800
attr di_TerrassenBeleuchtung_Simulation room AußenLicht
attr di_TerrassenBeleuchtung_Simulation sortby 04
EDITH://
wenn ich das so vergleiche mit deinem Vorschlag habe ich das glaube ich so gemacht. Ich stehe nur etwas auf Kriegsfuß mit diesen ganzen Warte- und Wiederholungszeiten, dass habe ich noch nicht begriffen.
Mir fehlt in den Attributen das von dir angegebene..!
- wait
- timerWithWait
Dazu muss ich glaube ich aus meinem Code diesen Teil raus nehmen
({(int(rand(1800)+300))})
Ich habe jetzt mal umgebaut und werde heute Abend mal schauen ob das so funktioniert, zumindest meckert das DOIF nicht beim speichern...!
define di_TerrassenBeleuchtung_Simulation DOIF ([?du_Modus_TerrassenBeleuchtung] eq "Zufall" and ([[du_Anfang_Zufall]])) (set NI3_LichtTerrasse on) DOELSEIF ([[du_Ende_Zufall]]) (set NI3_LichtTerrasse off)
attr di_TerrassenBeleuchtung_Simulation alias Anwesenheitssimulation Licht Terrasse
attr di_TerrassenBeleuchtung_Simulation cmdState EIN|AUS
attr di_TerrassenBeleuchtung_Simulation do always
attr di_TerrassenBeleuchtung_Simulation group Anwesenheitssimulation Terrasse
attr di_TerrassenBeleuchtung_Simulation icon light_on-for-timer@blue
attr di_TerrassenBeleuchtung_Simulation repeatcmd rand(3600)+1800
attr di_TerrassenBeleuchtung_Simulation room AußenLicht
attr di_TerrassenBeleuchtung_Simulation sortby 04
attr di_TerrassenBeleuchtung_Simulation timerWithWait 1
attr di_TerrassenBeleuchtung_Simulation wait 1800,300
EDITH:// ging gar nicht erst an... :-\
ich habe nun heute den ganzen Tag mal ein Test DOIF laufen - welches mir einen freien Kanal meines 4-Kanal nutzt - bevor ich das produktiv einsetze, aber es schaltet sich die Beleuchtung immer nur ein ich sehe im Log kein ausgehen..
Ich denke das liegt an dem attr repeatcmd welches ich noch nicht so richtig begriffen habe.
Generell mal die Frage..
Der erste Teil ist ja für den ersten DO-Fall das Einschalten der Teil nach dem Doppelpunkt für den zweiten DO-Fall, dass Ausschalten, ist das richtig..?
rand(1200) macht das zufällige und die was macht die zweite Zahl hinter dem "+"..?
Ich finde dazu leider in der commandref kein solch kombiniertes Beispiel
Internals:
CFGFN ./FHEM/AussenBeleuchtung.cfg
DEF ([?du_Modus_TerrassenBeleuchtung] eq "Zufall" and ([[du_Anfang_Zufall_WoT]|8] or [[du_Anfang_Zufall_WoE]|7])) (set Dachlicht_03 on) DOELSEIF ([[du_Ende_Zufall]]) (set Dachlicht_03 off)
NAME di_TerrassenBeleuchtung_Simulation1
NR 1007
NTFY_ORDER 50-di_TerrassenBeleuchtung_Simulation1
STATE EIN
TYPE DOIF
Readings:
2016-01-22 14:05:02 Event wait_timer: no timer
2016-01-22 14:05:02 cmd_event timer_1
2016-01-22 14:05:02 cmd_nr 1
2016-01-22 14:05:02 state EIN
2016-01-22 04:00:00 timer_1_c1 23.01.2016 04:00:00|8
2016-01-22 06:20:00 timer_2_c1 23.01.2016 06:20:00|7
2016-01-22 00:40:00 timer_3_c2 23.01.2016 00:40:00
2016-01-22 14:05:02 wait_timer 22.01.2016 14:24:49 cmd_1 timer_1
Condition:
0 InternalDoIf('du_Modus_TerrassenBeleuchtung','STATE','',AttrVal($hash->{NAME},'notexist',undef)) eq "Zufall" and (DOIF_time_once($hash,$hash->{timer}{0},$wday,"8") or DOIF_time_once($hash,$hash->{timer}{1},$wday,"7"))
1 DOIF_time_once($hash,$hash->{timer}{2},$wday,"")
Days:
0 8
1 7
Devices:
Do:
0:
0 set Dachlicht_03 on
1:
0 set Dachlicht_03 off
2:
Helper:
event loadLvl: low
globalinit 1
last_timer 3
sleepdevice timer_1
sleepsubtimer 0
sleeptimer 0
triggerDev HMUSB
triggerEvents:
loadLvl: low
Internals:
0 du_Modus_TerrassenBeleuchtung:STATE
all du_Modus_TerrassenBeleuchtung:STATE
Itimer:
all du_Anfang_Zufall_WoT du_Anfang_Zufall_WoE du_Ende_Zufall
Readings:
Realtime:
0 04:00:00
1 06:20:00
2 00:40:00
Regexp:
State:
Time:
0 [du_Anfang_Zufall_WoT]
1 [du_Anfang_Zufall_WoE]
2 [du_Ende_Zufall]
Timecond:
0 0
1 0
2 1
Timer:
0 0
1 0
2 0
Timerfunc:
Timers:
0 0 1
1 2
Attributes:
alias Anwesenheitssimulation Licht Terrasse
cmdState EIN|AUS
do always
group Anwesenheitssimulation
icon light_on-for-timer@blue
repeatcmd rand(3600)+1800:rand(900)+900
room AußenLicht
sortby 05
timerWithWait 1
wait rand(600):rand(300)
Zitat von: Ellert am 21 Januar 2016, 08:50:00
Im Prinzip geht es so:
([<Zeitspanne>]) (<Einschaltbefehl>) (<Ausschaltbefehl>)
wait <Zufallszeitdauer1>, <Zufallszeitdauer2>
repeatcmd <maximale Zufallszeitdauer1 plus maximale Zufallszeitdauer2>
timerWithWait
do always
Und konkret sieht es so aus:
([18:00-23:00]) (set Dachlicht_03 on ) (set Dachlicht_03 off)wait rand(1800),rand(1800) wartet eine zufällige Zeit bis Befehl 1 ausgeführt wird und danach eine zufällige Zeit bis Befehl 2 ausgeführt wird.
repeatcmd 3610 wiederholt den Befehlszweig alle 1800+1800+10 Sekunden, (+10) damit die Wiederholung auf jeden Fall nach rand(1800)+rand(1800) stattfindet und immer ausgeschaltet wird,
timerWithwait
do always
rand(1200) macht das zufällige und die was macht die zweite Zahl hinter dem "+"..? Sie verlängert die zufällige Zeit um einen festen Wert.
ZitatDer erste Teil ist ja für den ersten DO-Fall das Einschalten der Teil nach dem Doppelpunkt für den zweiten DO-Fall, dass Ausschalten, ist das richtig..?
Ja, aber
ZitatBeispieldefinition bei mehreren DO-Blöcken mit mehreren Sequenzen:
DOIF (Bedingung1)
(set ...) ## erster Befehl der ersten Sequenz soll um eine Sekunde verzögert werden
(set ...) ## zweiter Befehl der ersten Sequenz soll um 2 Sekunden verzögert werden
DOELSE (Bedingung2)
(set ...) ## erster Befehl der zweiten Sequenz soll um 3 Sekunden verzögert werden
(set ...) ## zweiter Befehl der zweiten Sequenz soll um 0,5 Sekunden verzögert werden
attr <DOIF-modul> wait 1,2:3,0.5
Für Kommandos ohne Verzögerung werden Sekundenangaben ausgelassen oder auf Null gesetzt. Die Verzögerungen werden nur auf Events angewandt und nicht auf Zeitsteuerung. Eine bereits ausgelöste Verzögerung wird zurückgesetzt, wenn während der Wartezeit ein Kommando eines anderen DO-Falls, ausgelöst durch ein neues Ereignis, ausgeführt werden soll.
OK das ist super erklärt :) jetzt sollte es mir gelingen mein DOIF in den Griff zu kriegen..! Besser es läuft schon mal Probe.
das mit dem "repeatcmd" ist aber auch schwierig zu verstehen, ich wäre niemals auf die Idee gekommen bei Zeiten zusammen zu addieren..! :-\ Ich dachte immer das muss jeweils einzeln hintereinander geschrieben werden.
Diese "repeatcmd" Zeiten kann ich doch nach belieben verändern ohne die "wait" Zeiten zu verändern. Wichtig hierbei ist, wenn ich erreichen möchte das das Licht ausgeht, dass die "repeatcmd" Zeiten größer sind als die "wait" Zeiten..? Richtig.?
ZitatDiese "repeatcmd" Zeiten kann ich doch nach belieben verändern ohne die "wait" Zeiten zu verändern. Wichtig hierbei ist, wenn ich erreichen möchte das das Licht ausgeht, dass die "repeatcmd" Zeiten größer sind als die "wait" Zeiten..? Richtig.?
Ja, das ist richtig.
na da habe ich ja wenigstens etwas verstanden...! ;)
Nun habe ich diese Nacht und auch jetzt am Tage diese Testsession mal laufen lassen und stelle fest das die Zeiten jetzt nicht optimal sind und diese gilt es jetzt zu modifizieren.
Mit diesen Zeiten:
repeatcmd 3610 und wait rand(1800),rand(1800) habe ich folgende Zeitspannen.
Eingeschaltet ist die Beleuchtung zwischen 3min. und 25min. aber ausgeschaltet ist sie jedes mal so fast genau 1 Stunde.
Das ist jetzt nicht so das was ich wollte.
Ich werde jetzt mal schauen wie ich das vernünftig in Griff bekomme zumal die Zeit für AUS zu lange ist und die für EIN zu kurz..!
ich habe jetzt mal ein paar Tests laufen lassen mit verscheidenen Einstellungen
Hier mal das Ergebnis
- wait: rand(1800),rand(1800)
- repeatcmd: 3610
Beleuchtung EIN - 3 bis 25 min.
Beleuchtung AUS - 1 Std. (immer gleich)
--------------------------------------------------
- wait: rand(450),rand(450)
- repeatcmd: 3610
Beleuchtung EIN - 1 bis 2 min.
Beleuchtung AUS - 1 Std. (immer gleich)
--------------------------------------------------
- wait: rand(1800),rand(1800)
- repeatcmd: 910
Beleuchtung EIN - 1 bis 27 min.
Beleuchtung AUS - 15min. (immer gleich)
--------------------------------------------------
- wait: rand(1800),rand(3600)
- repeatcmd: 300
Beleuchtung EIN - 2 bis 60 min.
Beleuchtung AUS - 5min. (immer gleich)
--------------------------------------------------
Was mir bisher nicht gelungen ist (durch Zeitmangel) auch die AUS Zeit unterschiedlich zu gestalten, so in dem Bereich bis 20 min. und genau die Einschaltdauer, da wären 1 Std. OK aber dann ein anders mal nur 2min. das ist zu wenig.
Man müsste dieses einstellen können so in der Art
Einschaltzeit - 30 min. bis 1 Std. 15min.
Ausschaltzeit - 10 min. bis 30 min. (glaube hier wäre dann "wait rand(1800)" möglich)
Geht das zu machen..?
Du könntest statt rand(1800) eine fixe Zeit einbauen
rand(t1)+t2,rand(t3)+t4 und
repeatcmd t1+t2+t3+t4+10 dann hast Du immer eine mindest Dauer für Ein und Aus.
ZitatBeleuchtung EIN - 3 bis 25 min.
Beleuchtung AUS - 1 Std. (immer gleich)
Zitatimmer gleich
das kann nur Zufall sein ;)
Zitat von: Ellert am 25 Januar 2016, 13:58:00
Du könntest statt rand(1800) eine fixe Zeit einbauen rand(t1)+t2,rand(t3)+t4 und
repeatcmd t1+t2+t3+t4+10 dann hast Du immer eine mindest Dauer für Ein und Aus.
Puuh, jetzt wird es schierig :-\ ;)
Naja ich sage mal das zufällige ist ja nicht schlecht, aber wenn die Einschaltzeit nur 1min. ist wäre mir das zu wenig wie oben schon geschrieben.
Zitat von: Ellert am 25 Januar 2016, 13:58:00
das kann nur Zufall sein ;)
das war bei allen 4 Tests immer der Fall, dass die Zeit zwar unterschiedlich war aber immer gleichlange Aus ;)
OK,
also ich mache dann mal einen Test mit
wait: rand(1800)+600,rand(1800)+600
repeatcmd: 4800
Mal schauen was das wird..? ich dachte ich habe es verstanden komme einfach mit den Zeiten nicht klar :-\
Damit Du dokumentierte Zeiten erhältst kannst Du ja mal mitloggen und den Befehlezweig mit
Zitat(set Dachlicht_03 on, ({Log 1, "Einschalten"})) (set Dachlicht_03 off, ({Log 1, "Ausschalten"}))
ergänzen.
Kann man die Attribute repeatcmd und repeatsame auch durch ein Notify auf einen Dummy füllen?
define doif_water DOIF ([[water1start]] and [water1repeat] > 0)(set Switch01 on-for-timer 10)
attr doif_water do always
attr doif_water repeatcmd 15
attr doif_water repeatsame 5
attr doif_water room Wohnzimmer
define notify_water1repeat notify water1repeat {fhem ("set doif_water1 repeatsame water1repeat")}
attr notify_water1repeat room Wohnzimmer
Aktuell wird mir nur ein komisches reading erzeugt:
2016-01-25 15:05:07 e_water1repeat_STATE 10
ZitatKann man die Attribute repeatcmd und repeatsame auch durch ein Notify auf einen Dummy füllen?
Ja, aber der Befehl zum Setzen eines Attributes lautet nicht "set" sondern "attr".
Hier mal die Ergebnisse vom heutigen Test mit folgenden Zeiten und wieder ist die Zeit für "AUS" immer gleich und diesmal sehr lang.
Einstellung:
repeatcmd: 4800 (ich habe hier die +10 vergessen)
wait: rand(1800)+600,rand(1800)+600
Zeit EIN ist von minimum 15 min. bis maximal 32 min.
Zeit AUS ist immer 1 Std. und 20 min.
2016.01.26 00:02:50 1: Ausschalten
2016.01.25 23:45:26 1: Einschalten
2016.01.25 22:25:26 1: Ausschalten
2016.01.25 22:01:23 1: Einschalten
2016.01.25 20:41:23 1: Ausschalten
2016.01.25 20:26:40 1: Einschalten
2016.01.25 19:06:40 1: Ausschalten
2016.01.25 18:37:38 1: Einschalten
2016.01.25 17:17:38 1: Ausschalten
2016.01.25 17:00:22 1: Einschalten
2016.01.25 15:40:22 1: Ausschalten
2016.01.25 15:08:09 1: Einschalten
Ich bekomme es nicht hin auch die Ausschaltzeit kürzer und unterschiedlich zu machen, die Einschaltzeit könnte auch bis zu 1 Std. sein.
Das werden meine Einstellungen für den Test über Nacht, mit Logik komme ich hier nicht weiter also muss ich probieren... :-\ ;)
repeatcmd: 3910
wait: rand(1200)+600,rand(1800)+300
ZitatZeit EIN ist von minimum 15 min. bis maximal 32 min.
Das sieht für mich wie erwartet aus. Die 120 min würde ich nicht erwarten, die scheinen irgendwie mit der Zeitangabe in repeatcmd zusammenzuhängen 4800 s sind 120 min.
Um das weiter zu untersuchen würde ich das Logging erweitern und die Events des DOIF mitloggen mit:
define Zeituntersuchung notify <doifname> {Log 1, "Name: $NAME, Event: $EVENT"}
Zitat von: Ellert am 25 Januar 2016, 20:15:12
Ja, aber der Befehl zum Setzen eines Attributes lautet nicht "set" sondern "attr".
Vielen Dank. Genau das habe ich gesucht.
Kann ich im Notify auch ein "Save config" mit aufrufen um die Änderungen auch in die Config Datei zu speichern?
Reicht ein einfaches
fhem("save")?
Warum sollte das nicht ausreichen? Probier es aus.
Konnte es jetzt wie folgt lösen. Vielen Dank:
define notify_water1repeat notify water1repeat {fhem("attr Bewaesserung_doif2 repeatsame $EVENT");fhem("save")}
Zitat von: Ellert am 26 Januar 2016, 08:42:43
Um das weiter zu untersuchen würde ich das Logging erweitern und die Events des DOIF mitloggen mit:
define Zeituntersuchung notify <doifname> {Log 1, "Name: $NAME, Event: $EVENT"}
OK, das logge ich mal mit
Hier nochmal das Ergebnis des letzten Tests heute Nacht/vormittag
Einstellung
repeatcmd: 3910
wait: rand(1200)+600,rand(1800)+300
Zeit EIN ist von minimum 10 min. bis maximal 31 min.
Zeit AUS ist immer 1 Std. und 05 min.
2016.01.26 11:55:32 1: Ausschalten
2016.01.26 11:45:22 1: Einschalten
2016.01.26 10:40:12 1: Ausschalten
2016.01.26 10:26:34 1: Einschalten
2016.01.26 09:21:24 1: Ausschalten
2016.01.26 09:08:36 1: Einschalten
2016.01.26 08:03:26 1: Ausschalten
2016.01.26 07:53:38 1: Einschalten
2016.01.26 06:48:28 1: Ausschalten
2016.01.26 06:17:04 1: Einschalten
2016.01.26 05:11:54 1: Ausschalten
2016.01.26 05:00:49 1: Einschalten
2016.01.26 03:55:39 1: Ausschalten
2016.01.26 03:34:35 1: Einschalten
2016.01.26 02:29:25 1: Ausschalten
2016.01.26 02:11:06 1: Einschalten
2016.01.26 01:05:56 1: Ausschalten
2016.01.26 00:45:11 1: EinschaltenBin ja mal gespannt ob ich hier irgendwann einen Plan rein kriege, damit ich weiß wenn ich eine Zeit verändere und vorallem an welcher Stelle ich das tun muss. :-\
Noch sehe ich nicht durch, wenn ich die Ausschalt-Zeit ändern möchte an welcher Stelle und genauso wenn ich die Einschalt-Zeit ändern möchte
Hier nun meine Ergebnis des loggens mit dem notify
Einstellung:
repeatcmd: 2710
wait: rand(600)+600,rand(1200)+300
Zeit EIN ist von minimum 8 min. bis maximal 25 min.
Zeit AUS ist immer 45 min.
2016.01.26 19:14:29 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 19:59:39 cmd_1_1 timer_1
2016.01.26 19:14:29 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1
2016.01.26 19:14:29 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 19:14:29 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 2
2016.01.26 19:14:29 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 19:14:29 1: Ausschalten
2016.01.26 19:14:29 3: CUL_HM set Dachlicht_03 off
2016.01.26 19:14:29 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 19:02:39 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 19:14:29 cmd_1_2 timer_1
2016.01.26 19:02:39 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1_1
2016.01.26 19:02:39 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 19:02:39 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 1
2016.01.26 19:02:39 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 19:02:39 1: Einschalten
2016.01.26 19:02:39 3: CUL_HM set Dachlicht_03 on
2016.01.26 19:02:39 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 18:17:29 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 19:02:39 cmd_1_1 timer_1
2016.01.26 18:17:29 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1
2016.01.26 18:17:29 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 18:17:29 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 2
2016.01.26 18:17:29 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 18:17:29 1: Ausschalten
2016.01.26 18:17:29 3: CUL_HM set Dachlicht_03 off
2016.01.26 18:17:29 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 17:56:34 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 18:17:29 cmd_1_2 timer_1
2016.01.26 17:56:34 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1_1
2016.01.26 17:56:34 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 17:56:34 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 1
2016.01.26 17:56:34 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 17:56:34 1: Einschalten
2016.01.26 17:56:34 3: CUL_HM set Dachlicht_03 on
2016.01.26 17:56:34 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 17:11:24 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 17:56:34 cmd_1_1 timer_1
2016.01.26 17:11:24 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1
2016.01.26 17:11:24 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 17:11:24 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 2
2016.01.26 17:11:24 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 17:11:24 1: Ausschalten
2016.01.26 17:11:24 3: CUL_HM set Dachlicht_03 off
2016.01.26 17:11:24 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 17:02:11 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 17:11:24 cmd_1_2 timer_1
2016.01.26 17:02:11 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1_1
2016.01.26 17:02:11 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 17:02:11 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 1
2016.01.26 17:02:11 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 17:02:11 1: Einschalten
2016.01.26 17:02:11 3: CUL_HM set Dachlicht_03 on
2016.01.26 17:02:11 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 16:17:01 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 17:02:11 cmd_1_1 timer_1
2016.01.26 16:17:01 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1
2016.01.26 16:17:01 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 16:17:01 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 2
2016.01.26 16:17:01 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 16:17:01 1: Ausschalten
2016.01.26 16:17:01 3: CUL_HM set Dachlicht_03 off
2016.01.26 16:17:01 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 16:09:32 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 16:17:01 cmd_1_2 timer_1
2016.01.26 16:09:32 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1_1
2016.01.26 16:09:32 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 16:09:32 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 1
2016.01.26 16:09:32 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 16:09:32 1: Einschalten
2016.01.26 16:09:32 3: CUL_HM set Dachlicht_03 on
2016.01.26 16:09:32 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 15:24:22 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 16:09:32 cmd_1_1 timer_1
2016.01.26 15:24:22 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1
2016.01.26 15:24:22 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 15:24:22 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 2
2016.01.26 15:24:22 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 15:24:22 1: Ausschalten
2016.01.26 15:24:22 3: CUL_HM set Dachlicht_03 off
2016.01.26 15:24:22 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 15:09:28 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 15:24:22 cmd_1_2 timer_1
2016.01.26 15:09:28 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1_1
2016.01.26 15:09:28 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 15:09:28 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 1
2016.01.26 15:09:28 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 15:09:28 1: Einschalten
2016.01.26 15:09:28 3: CUL_HM set Dachlicht_03 on
2016.01.26 15:09:28 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 14:24:18 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 15:09:28 cmd_1_1 timer_1
2016.01.26 14:24:18 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1
2016.01.26 14:24:18 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 14:24:18 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 2
2016.01.26 14:24:18 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 14:24:18 1: Ausschalten
2016.01.26 14:24:18 3: CUL_HM set Dachlicht_03 off
2016.01.26 14:24:18 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 14:20:39 3: at_KalenderTermine_S: Wrote configuration to fhem.cfg
2016.01.26 14:20:39 3: save : Wrote configuration to fhem.cfg
2016.01.26 14:10:40 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 14:24:18 cmd_1_2 timer_1
2016.01.26 14:10:40 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1_1
2016.01.26 14:10:40 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 14:10:40 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 1
2016.01.26 14:10:40 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 14:10:40 1: Einschalten
2016.01.26 14:10:40 3: CUL_HM set Dachlicht_03 on
2016.01.26 14:10:40 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 13:25:30 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 14:10:40 cmd_1_1 timer_1
2016.01.26 13:25:30 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1
2016.01.26 13:25:30 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 13:25:30 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 2
2016.01.26 13:25:30 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 13:25:30 1: Ausschalten
2016.01.26 13:25:30 3: CUL_HM set Dachlicht_03 off
2016.01.26 13:25:30 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: no timer
2016.01.26 13:00:40 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: wait_timer: 26.01.2016 13:25:30 cmd_1_2 timer_1
2016.01.26 13:00:40 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_1_1
2016.01.26 13:00:40 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_event: timer_1
2016.01.26 13:00:40 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_seqnr: 1
2016.01.26 13:00:40 1: Name: di_TerrassenBeleuchtung_Simulation1, Event: cmd_nr: 1
2016.01.26 13:00:40 1: Einschalten
Es scheint so, dass einmal der zufällige wait-Timer und das andere Mal der feste repeatcmd-Timer die Zeiten bestimmt.
Nach dem ich hier: http://fhem.de/commandref_DE.html#DOIF_wait nachgelesen habe, denke ich die Berechnung funktioniert nur bei einfachen wait mit Doppelpunkt, nur dort wird die Berechnung erwähnt. Dass es auch bei Komma getrennten wait-Zeiten klappen müsste, habe ich wohl falsch interpretiert.
Neue Idee:
([18:00-23:00]) (IF ([Dachlicht_03] eq "off") (set Dachlicht_03 on ) ELSE (set Dachlicht_03 off))
wait rand(600)+300
repeatcmd 910
ich habe da schon hoch und runter gelesen, aber umso mehr ich lese umso weniger verstehe ich das alles, weil verwirrt...! ;)
Ich fahre jetzt mal den Test mit den von vorgeschlagenen Werten und werde später wieder dazu schreiben
@Ellert
EDITH:// geht gar nicht, schaltet immer nur AUS :-\
Ich werde jetzt nochmal die Zeiten für die Nacht umändern, dann lebe ich damit das die Ausschaltzeit immer gleich ist, aber ich versuche sie kurz zu halten so bis 15min. und die Einschaltzeit soll variieren zwischen 30min. bis 60min. :D wie gesagt ich versuche ;)
Zitat von: Ellert am 26 Januar 2016, 20:36:57
Nach dem ich hier: http://fhem.de/commandref_DE.html#DOIF_wait nachgelesen habe, denke ich die Berechnung funktioniert nur bei einfachen wait mit Doppelpunkt, nur dort wird die Berechnung erwähnt. Dass es auch bei Komma getrennten wait-Zeiten klappen müsste, habe ich wohl falsch interpretiert.
Die Berechnung wird auch bei Komma ausgeführt.
Gruß
Damian
Das müsste klappen ich habe es probiert:
([18:00-23:00]) () (set Dachlicht_03 on ) (set Dachlicht_03 off)
wait 0,rand(600)+300,rand(600)+300
repeatcmd 1
repeatcmd wird erst nach Ausführung aller Sequenzen berechnet und kollidiert mit dem 1. Zufallstimer, daher einmal () und wait 0,...
Meine Ergebnisse aus der Nacht bis heute morgen.
Einstellung
repeatcmd: 900
wait: rand(1800)+300,rand(3600)+1800
Zeit EIN ist von minimum 40 min. bis maximal 1 h 23 min.
Zeit AUS ist immer 15 min.
damit könnte ich leben, die Ausschaltzeit ist zwar immer gleich aber das ist OK die Einschaltzeit variiert nun soweit wie ich es möchte.
2016.01.27 12:58:00 1: Ausschalten
2016.01.27 12:18:30 1: Einschalten
2016.01.27 12:03:30 1: Ausschalten
2016.01.27 10:50:41 1: Einschalten
2016.01.27 10:35:40 1: Ausschalten
2016.01.27 09:53:16 1: Einschalten
2016.01.27 09:38:16 1: Ausschalten
2016.01.27 08:44:31 1: Einschalten
2016.01.27 08:29:31 1: Ausschalten
2016.01.27 07:15:26 1: Einschalten
2016.01.27 07:00:26 1: Ausschalten
2016.01.27 05:46:49 1: Einschalten
2016.01.27 05:31:49 1: Ausschalten
2016.01.27 04:38:06 1: Einschalten
2016.01.27 04:23:06 1: Ausschalten
2016.01.27 03:17:32 1: Einschalten
2016.01.27 03:02:32 1: Ausschalten
2016.01.27 01:39:34 1: Einschalten
Ich werde mir jetzt eine zweite Simulation/DOIF bauen und die neue Idee von dir probieren
Übrigens mal einen großen Dank für die tolle Unterstützung ;) :D
@Damian: Mich hat das von moonsorrox beobachtete Verhalten des DOIF irritiert und habe es nachgestellt, mit dem Ergebnis:
Bei Verwendung von erweitertem wait zusammen mit repeatcmd, wird der 1. wait-Timer nicht beachtet.
Verwendete DOIF-Version: DOIF-Testversion V 0.5
Loggendes notify:
anaus {Log 1, "notify $NAME: $EVENT"}Beobachtetes DOIF:
anaus DOIF ([13:45-18:00]) (({Log 1,"DOIF anaus: Einschalten"})) (({Log 1,"DOIF anaus: Ausschalten"}))
wait 10,14
repeatcmd 1
Zitat
+++++++++ 1. Runde
1. timer (10 s) ignoriert
2016.01.27 13:45:00 1: DOIF anaus: Einschalten
2016.01.27 13:45:00 1: notify anaus: cmd_nr: 1
2016.01.27 13:45:00 1: notify anaus: cmd_seqnr: 1
2016.01.27 13:45:00 1: notify anaus: cmd_event: timer_1
2016.01.27 13:45:00 1: notify anaus: cmd_1_1
2016.01.27 13:45:00 1: notify anaus: wait_timer: 27.01.2016 13:45:14 cmd_1_2 timer_1
2. timer (15 s) gesetzt
2016.01.27 13:45:14 1: notify anaus: wait_timer: no timer
2016.01.27 13:45:14 1: DOIF anaus: Ausschalten
2016.01.27 13:45:14 1: notify anaus: cmd_nr: 1
2016.01.27 13:45:14 1: notify anaus: cmd_seqnr: 2
2016.01.27 13:45:14 1: notify anaus: cmd_event: timer_1
2016.01.27 13:45:14 1: notify anaus: cmd_1
2016.01.27 13:45:14 1: notify anaus: wait_timer: 27.01.2016 13:45:15 cmd_1_1 timer_1
+++++++++ 2. Runde
1. timer (10 s) ignoriert, stattdessen repeatcmd-Zeit (1 s) verwendet
2016.01.27 13:45:15 1: notify anaus: wait_timer: no timer
2016.01.27 13:45:15 1: DOIF anaus: Einschalten
2016.01.27 13:45:15 1: notify anaus: cmd_nr: 1
2016.01.27 13:45:15 1: notify anaus: cmd_seqnr: 1
2016.01.27 13:45:15 1: notify anaus: cmd_event: timer_1
2016.01.27 13:45:15 1: notify anaus: cmd_1_1
2016.01.27 13:45:15 1: notify anaus: wait_timer: 27.01.2016 13:45:29 cmd_1_2 timer_1
2. timer (14 s) gesetzt
2016.01.27 13:45:29 1: notify anaus: wait_timer: no timer
2016.01.27 13:45:29 1: DOIF anaus: Ausschalten
2016.01.27 13:45:29 1: notify anaus: cmd_nr: 1
2016.01.27 13:45:29 1: notify anaus: cmd_seqnr: 2
2016.01.27 13:45:29 1: notify anaus: cmd_event: timer_1
2016.01.27 13:45:29 1: notify anaus: cmd_1
2016.01.27 13:45:29 1: notify anaus: wait_timer: 27.01.2016 13:45:30 cmd_1_1 timer_1
1. Runde: Die erste wait-Zeit von 10 s wird nicht beachtet.
2. Runde: Statt der ersten wait-Zeit von 10 s, wird die repeatcmd-Zeit von 1 s aktiv und danach die zweite wait-Zeit von 14 s.
Habe ich das richtig interpretiert?
Das Verhalten kann man umgehen, wenn ein 0 Timer im wait-Abschnitt der zu wiederholenden Sequenzen vorangestellt wird und eine leere Sequenz an den Anfang des zugehörigen Bedingungszweig eingefügt wird.
Zitat von: Ellert am 27 Januar 2016, 14:47:12
@Damian: Mich hat das von moonsorrox beobachtete Verhalten des DOIF irritiert und habe es nachgestellt, mit dem Ergebnis:
Bei Verwendung von erweitertem wait zusammen mit repeatcmd, wird der 1. wait-Timer nicht beachtet.
Verwendete DOIF-Version: DOIF-Testversion V 0.5
Loggendes notify:
anaus {Log 1, "notify $NAME: $EVENT"}
Beobachtetes DOIF:
anaus DOIF ([13:45-18:00]) (({Log 1,"DOIF anaus: Einschalten"})) (({Log 1,"DOIF anaus: Ausschalten"}))
wait 10,14
repeatcmd 1
1. Runde: Die erste wait-Zeit von 10 s wird nicht beachtet.
2. Runde: Statt der ersten wait-Zeit von 10 s, wird die repeatcmd-Zeit von 1 s aktiv und danach die zweite wait-Zeit von 14 s.
Habe ich das richtig interpretiert?
Das Verhalten kann man umgehen, wenn ein 0 Timer im wait-Abschnitt der zu wiederholenden Sequenzen vorangestellt wird und eine leere Sequenz an den Anfang des zugehörigen Bedingungszweig eingefügt wird.
Der Trigger kommt vom Zeitintervall, daher greift das erste wait nicht. Mit dem Attribut timerWithWait, sollte das aber funktionieren. Zitat aus der Commandref:
ZitatFür Kommandos ohne Verzögerung werden Sekundenangaben ausgelassen oder auf Null gesetzt. Die Verzögerungen werden nur auf Events angewandt und nicht auf Zeitsteuerung. Eine bereits ausgelöste Verzögerung wird zurückgesetzt, wenn während der Wartezeit ein Kommando eines anderen DO-Falls, ausgelöst durch ein neues Ereignis, ausgeführt werden soll.
Verzögerungen von Timern
Verzögerungen können mit Hilfe des Attributs timerWithWait auf Timer ausgeweitet werden.
Gruß
Damian
Danke für den Hinweis, darauf hätte ich eigentlich selbst kommen müssen, ich habe es schon mehrfach gelesen und auch schon benutzt.
OK nun mal die Ergebnisse der zweiten Variante der Simulation
DEF
([13:35-23:00]) () (set Dachlicht_03 on, ({Log 1, "Einschalten"})) (set Dachlicht_03 off, ({Log 1, "Ausschalten"}))
Einstellung
repeatcmd: 1
wait: 0,rand(600)+300,rand(600)+300
Zeit EIN ist von minimum 6 min. bis maximal 15 min.
Zeit AUS ist minimum 5 min. bis maximal 15 min.
So scheint das jetzt also mit unterschiedlicher EIN/AUS Zeit zu funktionieren
Ich habe jetzt die Zeiten verändert und teste es weiter, die Pausenzeit ist OK und die Einschaltzeit versuche ich auf ca. minimum 30 min. bis maximum 1 h 20 min. zu bekommen
2016.01.27 16:53:08 1: Ausschalten
2016.01.27 16:53:08 3: CUL_HM set Dachlicht_03 off
2016.01.27 16:53:08 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 16:44:44 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 16:53:08 cmd_1_3 timer_1
2016.01.27 16:44:44 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_2
2016.01.27 16:44:44 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 16:44:44 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 2
2016.01.27 16:44:44 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 16:44:44 1: Einschalten
2016.01.27 16:44:44 3: CUL_HM set Dachlicht_03 on
2016.01.27 16:44:44 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 16:29:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 16:44:44 cmd_1_2 timer_1
2016.01.27 16:29:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_1
2016.01.27 16:29:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 16:29:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 1
2016.01.27 16:29:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 16:29:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 16:29:46 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 16:29:47 cmd_1_1 timer_1
2016.01.27 16:29:46 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1
2016.01.27 16:29:46 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 16:29:46 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 3
2016.01.27 16:29:46 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 16:29:46 1: Ausschalten
2016.01.27 16:29:46 3: CUL_HM set Dachlicht_03 off
2016.01.27 16:29:46 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 16:21:22 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 16:29:46 cmd_1_3 timer_1
2016.01.27 16:21:22 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_2
2016.01.27 16:21:22 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 16:21:22 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 2
2016.01.27 16:21:22 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 16:21:22 1: Einschalten
2016.01.27 16:21:22 3: CUL_HM set Dachlicht_03 on
2016.01.27 16:21:22 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 16:17:48 3: CUL_HM set Ladestation_kueche on
2016.01.27 16:15:48 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 16:21:22 cmd_1_2 timer_1
2016.01.27 16:15:48 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_1
2016.01.27 16:15:48 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 16:15:48 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 1
2016.01.27 16:15:48 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 16:15:48 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 16:15:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 16:15:48 cmd_1_1 timer_1
2016.01.27 16:15:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1
2016.01.27 16:15:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 16:15:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 3
2016.01.27 16:15:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 16:15:47 1: Ausschalten
2016.01.27 16:15:47 3: CUL_HM set Dachlicht_03 off
2016.01.27 16:15:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 16:09:23 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 16:15:47 cmd_1_3 timer_1
2016.01.27 16:09:23 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_2
2016.01.27 16:09:23 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 16:09:23 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 2
2016.01.27 16:09:23 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 16:09:23 1: Einschalten
2016.01.27 16:09:23 3: CUL_HM set Dachlicht_03 on
2016.01.27 16:09:23 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 16:01:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 16:09:23 cmd_1_2 timer_1
2016.01.27 16:01:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_1
2016.01.27 16:01:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 16:01:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 1
2016.01.27 16:01:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 16:01:47 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 16:01:46 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 16:01:47 cmd_1_1 timer_1
2016.01.27 16:01:46 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1
2016.01.27 16:01:46 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 16:01:46 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 3
2016.01.27 16:01:46 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 16:01:46 1: Ausschalten
2016.01.27 16:01:46 3: CUL_HM set Dachlicht_03 off
2016.01.27 16:01:46 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 15:55:18 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 16:01:46 cmd_1_3 timer_1
2016.01.27 15:55:18 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_2
2016.01.27 15:55:18 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 15:55:18 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 2
2016.01.27 15:55:18 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 15:55:18 1: Einschalten
2016.01.27 15:55:18 3: CUL_HM set Dachlicht_03 on
2016.01.27 15:55:18 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 15:42:10 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 15:55:18 cmd_1_2 timer_1
2016.01.27 15:42:10 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_1
2016.01.27 15:42:10 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 15:42:10 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 1
2016.01.27 15:42:10 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 15:42:10 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 15:42:09 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 15:42:10 cmd_1_1 timer_1
2016.01.27 15:42:09 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1
2016.01.27 15:42:09 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 15:42:09 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 3
2016.01.27 15:42:09 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 15:42:09 1: Ausschalten
2016.01.27 15:42:09 3: CUL_HM set Dachlicht_03 off
2016.01.27 15:42:09 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 15:29:39 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 15:42:09 cmd_1_3 timer_1
2016.01.27 15:29:39 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_2
2016.01.27 15:29:39 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 15:29:39 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 2
2016.01.27 15:29:39 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 15:29:39 1: Einschalten
2016.01.27 15:29:39 3: CUL_HM set Dachlicht_03 on
2016.01.27 15:29:39 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 15:17:18 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 15:29:39 cmd_1_2 timer_1
2016.01.27 15:17:18 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_1
2016.01.27 15:17:18 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 15:17:18 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 1
2016.01.27 15:17:18 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 15:17:18 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 15:17:17 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 15:17:18 cmd_1_1 timer_1
2016.01.27 15:17:17 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1
2016.01.27 15:17:17 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 15:17:17 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 3
2016.01.27 15:17:17 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 15:17:17 1: Ausschalten
2016.01.27 15:17:17 3: CUL_HM set Dachlicht_03 off
2016.01.27 15:17:17 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 15:02:44 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 15:17:17 cmd_1_3 timer_1
2016.01.27 15:02:44 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_2
2016.01.27 15:02:44 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 15:02:44 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 2
2016.01.27 15:02:44 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 15:02:44 1: Einschalten
2016.01.27 15:02:44 3: CUL_HM set Dachlicht_03 on
2016.01.27 15:02:44 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 14:57:05 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 15:02:44 cmd_1_2 timer_1
2016.01.27 14:57:05 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_1
2016.01.27 14:57:05 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 14:57:05 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 1
2016.01.27 14:57:05 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 14:57:05 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 14:57:04 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 14:57:05 cmd_1_1 timer_1
2016.01.27 14:57:04 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1
2016.01.27 14:57:04 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 14:57:04 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 3
2016.01.27 14:57:04 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 14:57:04 1: Ausschalten
2016.01.27 14:57:04 3: CUL_HM set Dachlicht_03 off
2016.01.27 14:57:04 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 14:44:12 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 14:57:04 cmd_1_3 timer_1
2016.01.27 14:44:12 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_2
2016.01.27 14:44:12 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 14:44:12 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 2
2016.01.27 14:44:12 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 14:44:12 1: Einschalten
2016.01.27 14:44:12 3: CUL_HM set Dachlicht_03 on
2016.01.27 14:44:12 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 14:32:51 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 14:44:12 cmd_1_2 timer_1
2016.01.27 14:32:51 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_1
2016.01.27 14:32:51 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 14:32:51 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 1
2016.01.27 14:32:51 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 14:32:51 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 14:32:50 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 14:32:51 cmd_1_1 timer_1
2016.01.27 14:32:50 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1
2016.01.27 14:32:50 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 14:32:50 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 3
2016.01.27 14:32:50 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 14:32:50 1: Ausschalten
2016.01.27 14:32:50 3: CUL_HM set Dachlicht_03 off
2016.01.27 14:32:50 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 14:26:57 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 14:32:50 cmd_1_3 timer_1
2016.01.27 14:26:57 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_2
2016.01.27 14:26:57 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 14:26:57 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 2
2016.01.27 14:26:57 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 14:26:57 1: Einschalten
2016.01.27 14:26:57 3: CUL_HM set Dachlicht_03 on
2016.01.27 14:26:57 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 14:13:25 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 14:26:57 cmd_1_2 timer_1
2016.01.27 14:13:25 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1_1
2016.01.27 14:13:25 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 14:13:25 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 1
2016.01.27 14:13:25 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 14:13:25 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 14:13:24 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: 27.01.2016 14:13:25 cmd_1_1 timer_1
2016.01.27 14:13:24 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_1
2016.01.27 14:13:24 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_event: timer_1
2016.01.27 14:13:24 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_seqnr: 3
2016.01.27 14:13:24 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: cmd_nr: 1
2016.01.27 14:13:24 1: Ausschalten
2016.01.27 14:13:24 3: CUL_HM set Dachlicht_03 off
2016.01.27 14:13:24 1: Name: di_TerrassenBeleuchtung_Simulation2, Event: wait_timer: no timer
2016.01.27 14:04:07 1: Einschalten
2016.01.27 14:04:07 3: CUL_HM set Dachlicht_03 on
2016.01.27 13:56:54 1: Ausschalten
2016.01.27 13:56:54 3: CUL_HM set Dachlicht_03 off
2016.01.27 13:44:23 1: Einschalten
2016.01.27 13:44:23 3: CUL_HM set Dachlicht_03 on
Wenn Du mit gelesen hast, weisst Du was falsch war:
Zitat([18:00-23:00]) () (set Dachlicht_03 on ) (set Dachlicht_03 off)
wait 0,rand(600)+300,rand(600)+300
repeatcmd 1
timerWithWait
aber das hatten wir doch in der 1. Variante der Simulation mit drin..? Auf diese bezog sich denke ich Damians Hinweis..
Denn die jetzige funktioniert doch nur eben das die Zeiten angepaßt werden müssen
Ja, Du hast recht, ich werde auch noch mal probieren.
Hier nun die Ergebnisse der zweiten Simulationszeit
Einstellung
repeatcmd: 1
wait: 0,rand(1800)+600,rand(600)+600
Zeit EIN ist von minimum 10 min. bis maximal 17 min.
Zeit AUS ist minimum 12 min. bis maximal 40 min.
Den Rest des Logs schenke ich mir hier mal, da wir ja wissen das es so funktioniert, nur ist für mich noch die Frage welcher Bereich der wait Einstellung ist für Ein und welcher für Aus
Für diese Dauer ist AUS rand(1800)+600 und für diese EIN rand(600)+600.
Zitat von: Damian am 27 Januar 2016, 17:54:22
Der Trigger kommt vom Zeitintervall, daher greift das erste wait nicht. Mit dem Attribut timerWithWait, sollte das aber funktionieren. Zitat aus der Commandref:
Gruß
Damian
@Damian: Ich habe es mit "timerWithWait" probiert. Das Verhalten hat sich nur wenig geändert.
Die 1. Runde funktioniert, wie erwartet.
ab der 2. Runde wird der 1. berechnete wait-Timer ignoriert.
Benutztes DOIF-Modul: Testversion 0.6
Untersuchtes DOIF:
([09:41:45]) (({Log 1,"DOIF anaus: Einschalten"})) (({Log 1,"DOIF anaus: Ausschalten"}))
wait (rand(5)+5),(rand(5)+5)
repeatcmd 1
timerWithWait
Das Logging dazu:
Zitat2016.01.28 09:41:41 1: notify anaus: initialized
++++++++ 1.Runde
2016.01.28 09:41:45 1: notify anaus: wait_timer: 28.01.2016 09:41:54 cmd_1_1 timer_1 wait1 = 9 s
2016.01.28 09:41:54 1: notify anaus: wait_timer: no timer
2016.01.28 09:41:54 1: DOIF anaus: Einschalten
2016.01.28 09:41:54 1: notify anaus: cmd_nr: 1
2016.01.28 09:41:54 1: notify anaus: cmd_seqnr: 1
2016.01.28 09:41:54 1: notify anaus: cmd_event: timer_1
2016.01.28 09:41:54 1: notify anaus: cmd_1_1
2016.01.28 09:41:54 1: notify anaus: wait_timer: 28.01.2016 09:42:03 cmd_1_2 timer_1 wait2 = 9 s
2016.01.28 09:42:03 1: notify anaus: wait_timer: no timer
2016.01.28 09:42:03 1: DOIF anaus: Ausschalten
2016.01.28 09:42:03 1: notify anaus: cmd_nr: 1
2016.01.28 09:42:03 1: notify anaus: cmd_seqnr: 2
2016.01.28 09:42:03 1: notify anaus: cmd_event: timer_1
2016.01.28 09:42:03 1: notify anaus: cmd_1
2016.01.28 09:42:03 1: notify anaus: wait_timer: 28.01.2016 09:42:04 cmd_1_1 timer_1 repeatcmd 1 s
++++++++ 2.Runde
2016.01.28 09:42:04 1: notify anaus: wait_timer: no timer danach müsste wait1 kommen
2016.01.28 09:42:04 1: DOIF anaus: Einschalten
2016.01.28 09:42:04 1: notify anaus: cmd_nr: 1
2016.01.28 09:42:04 1: notify anaus: cmd_seqnr: 1
2016.01.28 09:42:04 1: notify anaus: cmd_event: timer_1
2016.01.28 09:42:04 1: notify anaus: cmd_1_1
2016.01.28 09:42:04 1: notify anaus: wait_timer: 28.01.2016 09:42:12 cmd_1_2 timer_1 wait2 = 8 s
2016.01.28 09:42:12 1: notify anaus: wait_timer: no timer
2016.01.28 09:42:12 1: DOIF anaus: Ausschalten
2016.01.28 09:42:12 1: notify anaus: cmd_nr: 1
2016.01.28 09:42:12 1: notify anaus: cmd_seqnr: 2
2016.01.28 09:42:12 1: notify anaus: cmd_event: timer_1
2016.01.28 09:42:12 1: notify anaus: cmd_1
2016.01.28 09:42:12 1: notify anaus: wait_timer: 28.01.2016 09:42:13 cmd_1_1 timer_1 repeatcmd 1 s
++++++++ 3.Runde
2016.01.28 09:42:13 1: notify anaus: wait_timer: no timer danach müsste wait1 kommen
2016.01.28 09:42:13 1: DOIF anaus: Einschalten
2016.01.28 09:42:13 1: notify anaus: cmd_nr: 1
2016.01.28 09:42:13 1: notify anaus: cmd_seqnr: 1
2016.01.28 09:42:13 1: notify anaus: cmd_event: timer_1
2016.01.28 09:42:13 1: notify anaus: cmd_1_1
2016.01.28 09:42:13 1: notify anaus: wait_timer: 28.01.2016 09:42:21 cmd_1_2 timer_1 wait2 8 s
2016.01.28 09:42:21 1: notify anaus: wait_timer: no timer
2016.01.28 09:42:21 1: DOIF anaus: Ausschalten
2016.01.28 09:42:21 1: notify anaus: cmd_nr: 1
2016.01.28 09:42:21 1: notify anaus: cmd_seqnr: 2
2016.01.28 09:42:21 1: notify anaus: cmd_event: timer_1
2016.01.28 09:42:21 1: notify anaus: cmd_1
2016.01.28 09:42:22 1: notify anaus: wait_timer: 28.01.2016 09:42:23 cmd_1_1 timer_1 repeatcmd 1 s
++++++++ 4.Runde
2016.01.28 09:42:23 1: notify anaus: wait_timer: no timer
Ergänzt: Testversion 0.7 zeigt das gleiche Verhalten
Zitat von: Ellert am 28 Januar 2016, 09:31:59
Für diese Dauer ist AUS rand(1800)+600 und für diese EIN rand(600)+600.
OK, dann gehe ich davon aus das bei meiner Einstellung unten für
AUS: die minimum Zeit 11min. und die maximum Zeit 40min. sein könnte und natürlich alles dazwischen
und für
EIN: die minimum Zeit 11min. und die maximum Zeit 70min. (war zufällig auch bei mir einmal der Fall) sein könnte. Weil für rand(x)macht er wohl in jedem Fall 1 Minute.
Das sind die Ergebnisse des letzten Testzeitraumes
Einstellung
repeatcmd: 1
wait: 0,rand(1800)+600,rand(3600)+600
Für AUS rand(1800)+600 und für EIN rand(3600)+600.
Zeit EIN ist von minimum 19 min. bis maximal 1 h 10 min.
Zeit AUS ist minimum 14 min. bis maximal 37 min.
Zitat von: Ellert am 28 Januar 2016, 10:27:59
@Damian: Ich habe es mit "timerWithWait" probiert. Das Verhalten hat sich nur wenig geändert.
Die 1. Runde funktioniert, wie erwartet.
ab der 2. Runde wird der 1. berechnete wait-Timer ignoriert.
Benutztes DOIF-Modul: Testversion 0.6
Untersuchtes DOIF:([09:41:45]) (({Log 1,"DOIF anaus: Einschalten"})) (({Log 1,"DOIF anaus: Ausschalten"}))
wait (rand(5)+5),(rand(5)+5)
repeatcmd 1
timerWithWait
Das Logging dazu:
Ergänzt: Testversion 0.7 zeigt das gleiche Verhalten
ja, es ist so programmiert, dass die Angabe bei repeatcmd sich auf die letzte Ausführung bezieht, dabei wird wait nicht mehr berücksichtigt.
Bei wait 5,5 und repeatcmd 10
bedeutet es:
00:00 trigger +5
00:05 cmd1_1 +5
00:10 cmd1_2 +10
00:20 cmd1_1 +5
00:25 cmd1_2 +5
00:35 cmd1_1 +10
...
Gruß
Damian
@Damian: Danke, für die Erläuterung.
@moonsorrox: Du hast jetzt zwar ein funktionierendes DOIF, aber es könnte (ohne leere Klammer) formuliert werden.
([<Zeitspanne>]) (set Dachlicht_03 on ) (set Dachlicht_03 off)
DOELSE (set Dachlicht_03 off) damit das Licht zum Schluss auch wirklich ausgeht.
wait rand(t_ein_zufall)+t_ein_fix, rand(t_aus_zufall)+t1_aus_fix
repeatcmd rand(t_ein_zufall)+t_ein_fix
timerWithWait
so ich habe das auch mal getestet und dieses ist meine DEF. damit ich das später so einbauen kann.
([?du_Modus_TerrassenBeleuchtung] eq "Zufall" and ([[du_Anfang_Zufall]]-[[du_Ende_Zufall]])) ()(set Dachlicht_03 on, ({Log 1, "Einschalten"})) (set Dachlicht_03 off, ({Log 1, "Ausschalten"}))
Einstellung
repeatcmd: rand(3600)+600
wait: rand(3600)+600, rand(900)+300
timerWithWait (hierzu muss ich sagen, da macht er mir immer eine 1 hinter)
Zeit EIN ist von minimum 5 min. bis maximal 20 min.
Zeit AUS ist minimum 22 min. bis maximal 57 min.
Irgendwie sind jetzt die Zeiten alle wieder viel kürzer...! ich habe mal verscuht hier unter es für mich zu verstehen, evtl. liege ich aber falsch.. bitte berichtigen falls ja..!
wenn ich jetzt mal diese von dir zu Grunde lege
wait rand(t_ein_zufall)+t_ein_fix, rand(t_aus_zufall)+t1_aus_fix
repeatcmd rand(t_ein_zufall)+t_ein_fix
sollte bei meinen Zeiten oben die zufällige Zahl von rand(t_ein_zufall) entweder als kleinste 1min. und als größte 60min. sein plus den fixen Wert für ein t_ein_fix 10min. sein.
Das kann so nicht stimmen, denn die kleinste Zeit ist immer 1min + 10min= 11min. und die größte sollte minimum 60+10min=70min. dieses ist aber nie passiert, denn schon die kleinste Zahl stimmt nicht die ist nämlich 5 gewesen und die größte bisher nur 20
Ebenso die ganze Sache bei der Auszeit, denn die größte Pausen ist nie eingetreten, nämlich t_aus_zufall + t1_aus_fix in Zahlen 15+5=20min. die ist größer gewesen bis viel größer.
Nun verstehe ich die ganze Logik überhaupt nicht mehr..!
Momentan läuft noch ein weiterer Test, denn er hat auch meine Ausschaltzeit ignoriert (du_Ende_Zufall) eingeschaltet hat er aber eben nicht mehr AUS.
Hier steht was rand leistet: http://perldoc.perl.org/functions/rand.html , rand(x) erzeugt Zahlen Z, für die gilt 0 <= Z < x.
Beispiel: rand(600), kleinste Zahl 0, grösste Zahl etwa 599,999999
Du beobachtest immer nur wenige erzeugte Zahlen. Damit kannst Du keine Grenzen ermitteln.
Für rand(600)+300 wird irgendwann eine Zahl 300 und eine Zahl 899.999999, Du konntest das bei 20 Versuchen zufällig nicht beobachten.
Zitatals kleinste 1min. und als größte 60min
das kann rand nicht leisten, das geht nur mit rand(540)+60
ZitatDas kann so nicht stimmen, denn die kleinste Zeit ist immer 1min + 10min= 11min. und die größte sollte minimum 60+10min=70min. dieses ist aber nie passiert, denn schon die kleinste Zahl stimmt nicht die ist nämlich 5 gewesen und die größte bisher nur 20
Ebenso die ganze Sache bei der Auszeit, denn die größte Pausen ist nie eingetreten, nämlich t_aus_zufall + t1_aus_fix in Zahlen 15+5=20min. die ist größer gewesen bis viel größer.
Nun verstehe ich die ganze Logik überhaupt nicht mehr..!
Mit diesem Beispiel:
ZitatEinstellung
repeatcmd: rand(3600)+600
wait: rand(3600)+600, rand(900)+300
ergeben sich folgende Grenzen:
1. Runde
kleinste Wartezeit 600 s (10 min) längste Wartezeit 4199,999999 s (~70 min), dann Einschalten
kleinste Wartezeit 300 s (5 min) längste Wartezeit 1199,999999 s (~20 min), dann Ausschalten
2. Runde
kleinste Wartezeit 600 s (10 min) längste Wartezeit 4199,999999 s (~70 min), dann Einschalten
kleinste Wartezeit 300 s (5 min) längste Wartezeit 1199,999999 s (~20 min), dann Ausschalten
.
.
.
Ich habe es im kleineren Masstab nachgestellt:
repeatcmd rand(360)+60
wait rand(360)+60,rand(90)+30
timerWithWait 1
Zitat17:29:00 Start
2016.01.29 16:34:50 1: DOIF anaus: Einschalten nach 350 s (min 60 s, max 420 s)
2016.01.29 16:36:26 1: DOIF anaus: Ausschalten nach 96 s (min 30 s, max 120 s)
2016.01.29 16:37:58 1: DOIF anaus: Einschalten nach 92 s (min 60 s, max 420 s)
2016.01.29 16:39:42 1: DOIF anaus: Ausschalten nach 104 s (min 30 s, max 120 s)
2016.01.29 16:42:01 1: DOIF anaus: Einschalten nach 139 s (min 60 s, max 420 s)
2016.01.29 16:43:27 1: DOIF anaus: Ausschalten nach 86 s (min 30 s, max 120 s)
2016.01.29 16:45:51 1: DOIF anaus: Einschalten nach 144 s (min 60 s, max 420 s)
2016.01.29 16:46:42 1: DOIF anaus: Ausschalten nach 51 s (min 30 s, max 120 s)
2016.01.29 16:50:44 1: DOIF anaus: Einschalten nach 242 s (min 60 s, max 420 s)
2016.01.29 16:51:18 1: DOIF anaus: Ausschalten nach 51 s (min 30 s, max 120 s)
2016.01.29 16:53:00 1: DOIF anaus: Einschalten nach 102 s (min 60 s, max 420 s)
2016.01.29 16:54:52 1: DOIF anaus: Ausschalten nach 112 s (min 30 s, max 120 s)
Ich kann keine unzulässige Abweichung erkennen.
Zitat von: Ellert am 29 Januar 2016, 16:59:07
Hier steht was rand leistet: http://perldoc.perl.org/functions/rand.html , rand(x) erzeugt Zahlen Z, für die gilt 0 <= Z < x.
Beispiel: rand(600), kleinste Zahl 0, grösste Zahl etwa 599,999999
OK, dann lag ich gar nicht so falsch ich hatte immer angenommen die kleinste Zahl ist "1" also nun ist sie "0"
Ich wollte damit auch nur sagen das die Zeiten für mich bei rand(600) zufällig eben jetzt minimal 0min. und dann eben 10min (9,9xxxx) sind.
Was ich damit sagen wollte für mich sah das nach umgekehrter EIN/AUS Schaltung aus, die Beleuchtung war länger AUS als sie EIN war..!
Nach dem Beispiel hier:
wait rand(t_ein_zufall)+t_ein_fix, rand(t_aus_zufall)+t1_aus_fix
repeatcmd rand(t_ein_zufall)+t_ein_fixIch werde das morgen nochmal mit kurzen Zeiten laufen lassen so wie du es getan hast, denn nach meinen Zeiten war die Beleuchtung immer nur kurz EIN aber lang AUS.
Kannst du mir etwas zu der Abschaltung sagen, denn diese hat bei mir nicht funktioniert mit meinem DEF.
EINschalten ging aber die ganze Simulation lief einfach weiter über die eingestellte Zeit.
Ich habe diese Variante jetzt mal im Einsatz
([?du_Modus_TerrassenBeleuchtung] eq "Zufall" and [[du_Anfang_Zufall]-[du_Ende_Zufall]]) (set Dachlicht_03 on, ({Log 1, "Einschalten"})) (set Dachlicht_03 off, ({Log 1, "Ausschalten"})) DOELSE (set Dachlicht_03 off, ({Log 1, "ZeitAus"}))Das war der letzte Stand, hier funktionierte es nicht, aber mal schauen ob das mit der jetzigen Version geht:
([?du_Modus_TerrassenBeleuchtung] eq "Zufall" and [[du_Anfang_Zufall]]-[[du_Ende_Zufall]]) (set Dachlicht_03 on, ({Log 1, "Einschalten"})) (set Dachlicht_03 off, ({Log 1, "Ausschalten"})) DOELSE (set Dachlicht_03 off, ({Log 1, "ZeitAus"}))
ZitatWas ich damit sagen wollte für mich sah das nach umgekehrter EIN/AUS Schaltung aus, die Beleuchtung war länger AUS als sie EIN war..!
Da haben wir uns missverstanden:
Bei
repeatcmd: rand(3600)+600
wait: rand(3600)+600, rand(900)+300
ist
rand(3600)+600 die Wartezeit bis zum Einschalten und
rand(900)+300 die Wartezeit bis zum Ausschalten
Wenn das
([?du_Modus_TerrassenBeleuchtung] eq "Zufall" and [[du_Anfang_Zufall]-[du_Ende_Zufall]])
(set Dachlicht_03 on, ({Log 1, "Einschalten"})) (set Dachlicht_03 off, ({Log 1, "Ausschalten"}))
DOELSE (set Dachlicht_03 off, ({Log 1, "ZeitAus"}))nicht klappt, dann versuch
([?du_Modus_TerrassenBeleuchtung] eq "Zufall" and [[du_Anfang_Zufall]-[du_Ende_Zufall]])
(set Dachlicht_03 on, ({Log 1, "Einschalten"})) (set Dachlicht_03 off, ({Log 1, "Ausschalten"}))
das hat bei mir funktioniert oder
([?du_Modus_TerrassenBeleuchtung] eq "Zufall" and [[du_Anfang_Zufall]])
(set Dachlicht_03 on, ({Log 1, "Einschalten"})) (set Dachlicht_03 off, ({Log 1, "Ausschalten"}))
DOELSEIF ([?du_Modus_TerrassenBeleuchtung] eq "Zufall" and [[du_Ende_Zufall]])
(set Dachlicht_03 off, ({Log 1, "Ausschalten"}))habe ich nicht ausprobiert.
Zitat von: Ellert am 30 Januar 2016, 09:40:32
Da haben wir uns missverstanden:
Bei
repeatcmd: rand(3600)+600
wait: rand(3600)+600, rand(900)+300
ist
rand(3600)+600 die Wartezeit bis zum Einschalten und
rand(900)+300 die Wartezeit bis zum Ausschalten
Ok, dann ist das klar und ich muss es nur anpassen, da sage ich mal Danke ;)
Die Abschaltung funktioniert nun mit meiner letzten Variante, ich darf nicht doppelt um die Zeit eckig klammern..! Das war mein Fehler..!
nun muss ich doch nochmal etwas fragen.
Zitat von: Ellert am 30 Januar 2016, 09:40:32
wait: rand(3600)+600, rand(900)+300
ist
rand(3600)+600 die Wartezeit bis zum Einschalten und
rand(900)+300 die Wartezeit bis zum Ausschalten
da mir dieses EIN/AUS schalten nun mittlerweile klar ist gibt es aber dann noch "repeatcmd"
repeatcmd: rand(3600)+600dieses spielt natürlich auch eine gehörige Rolle,
kann ich das komplett weglassen, ich habe es jetzt noch nicht probiert, was ich gemacht habe:
diese wait Zeiten sind beides mal gleich geblieben
rand(90)+30, rand(360)+60 und repeatcmd habe ich jeweils mal geändert, das gibt komplett andere Zeiten
1. Variante - rand(360)+60
2. Variante - rand(90)+30
Habe schon gemerkt wenn dieses nicht da wäre gibt es keine Wiederholung...!
Hallo,
Hat sich an der Funktion etwas seit dem letzten Update getan?
Ich bekomme leider einen Fehler bei folgendem Code:
define water1start dummy
attr water1start room Pflanzen
attr water1start setList state:time
attr water1start userReadings Stunde {()},Minute {()},
attr water1start webCmd state
define water1repeat dummy
attr water1repeat room Pflanzen
attr water1repeat setList state:slider,0,1,10
attr water1repeat webCmd state
define water1interval dummy
attr water1interval room Pflanzen
attr water1interval setList state:slider,10,5,100
attr water1interval webCmd state
define Bewaesserung_doif DOIF ([[water1start]] and [water1repeat] > 0) (set Switch01 on-for-timer 60)
attr Bewaesserung_doif do always
attr Bewaesserung_doif repeatcmd [water1interval]
attr Bewaesserung_doif repeatsame [water1repeat]
attr Bewaesserung_doif room Pflanzen
Fehlermeldung:
2016.02.22 14:58:00 1: PERL WARNING: Argument "[water1repeat]" isn't numeric in numeric lt (<) at ./FHEM/98_DOIF.pm line 885.
diese Meldungen bekomme ich auch habe dazu auch schon gefragt, aber bisher noch keine Antwort bekommen...!
Ich denke er erwartet einen numerischen Code, deshalb die Warnung
Ich weiß aber, dass es schon einmal funktioniert hat. Ich wollte die Elemente jetzt nur noch über FTUI einstellbar machen und habe gemerkt, dass es nicht mehr geht.
Zitat von: gloob am 22 Februar 2016, 15:05:57
Ich weiß aber, dass es schon einmal funktioniert hat. Ich wollte die Elemente jetzt nur noch über FTUI einstellbar machen und habe gemerkt, dass es nicht mehr geht.
Welche DOIF-Version?
ich habe diese "98_DOIF.pm 10899 2016-02-21 12:41:29Z damian-s "
hatte diese Warnung schon hier (http://forum.fhem.de/index.php/topic,49680.msg413752.html#msg413752) geschildert
@gloob
Also bei repeatsame sowie repeatcmd kann man nur Zahlen angeben. Nur bei wait kann man Dummys auswerten lassen, das steht auch so in der Commandref. Mir ist keine DOIF-Version bekannt, wo es für repeatsame oder repeadcmd ausprogrammiert wäre.
@moonsorrox
Wenn man einen nicht numerischen Wert mit größer oder kleiner vergleicht, dann gibt es eine Warnung vom Perl-Interpreter, denn dieser wertet die Bedingung aus. Ich habe es mit der jetzigen Version, wie auch mit einer vom Mai getestet und in beiden Fällen kommt diese Warnung. Es ist also immer schon so gewesen.
Gruß
Damian
Zitat von: Damian am 22 Februar 2016, 18:34:51
@moonsorrox
Wenn man einen nicht numerischen Wert mit größer oder kleiner vergleicht, dann gibt es eine Warnung vom Perl-Interpreter, denn dieser wertet die Bedingung aus. Ich habe es mit der jetzigen Version, wie auch mit einer vom Mai getestet und in beiden Fällen kommt diese Warnung. Es ist also immer schon so gewesen.
Gruß
Damian
Problem ist mit einem numerischen Wert funktioniert es nicht..! muss ich das wohl akzeptieren oder irgendwie ändern.
Hatte da schon einige Versuche, aber da ging gar nichts mehr :-\
Das neue DOIF hat eine Ausgabeformatierung http://fhem.de/commandref_DE.html#DOIF_Filtern_nach_Zahlen , damit kannst Du den Wert über eine Regex vielleicht verändern:
[<Geraet>:<Reading>:"s/<zu suchender Begriff>/<Ersatzwert>/"]
Der zu suchende Begriff und der Ersatzwert können reguläre Ausdrücke sein.
Eine umfangreiche Beschreibung dazu findest Du hier http://perldoc.perl.org/perlre.html (http://perldoc.perl.org/perlre.html)
Zitat von: Ellert am 22 Februar 2016, 19:15:32
Das neue DOIF hat eine Ausgabeformatierung http://fhem.de/commandref_DE.html#DOIF_Filtern_nach_Zahlen , damit kannst Du den Wert über eine Regex vielleicht verändern:
[<Geraet>:<Reading>:"s/<zu suchender Begriff>/<Ersatzwert>/"]
Der zu suchende Begriff und der Ersatzwert können reguläre Ausdrücke sein.
Eine umfangreiche Beschreibung dazu findest Du hier http://perldoc.perl.org/perlre.html (http://perldoc.perl.org/perlre.html)
Das mit dem Suchen und Ersetzen geht bei dem neuen Features so nicht. Es wird gematched und Sachen in runden Klammern werden in Variablen $1, $2 usw. abgespeichert (Perlfunktinalität), auf die man im letzten Parameter Output wieder zugreifen kann.
Gruß
Damian
Würde sowas funktionieren ?[<Geraet>:<Reading>:d:($1 == 0 ? "Runter" : "none")]
Zitat von: Ellert am 22 Februar 2016, 20:18:24
Würde sowas funktionieren ?[<Geraet>:<Reading>:d:($1 == 0 ? "Runter" : "none")]
von der Syntax schon, aber die Warnung lautet:
Zitat2016.02.21 14:32:15 1: PERL WARNING: Argument "Runter" isn't numeric in numeric le (<=) at (eval 196330) line 1.
Es sind ja die
nicht numerischen Werte das Problem und nicht die numerischen.
Zitat von: Damian am 22 Februar 2016, 20:42:07
von der Syntax schon, aber die Warnung lautet:
Es sind ja die nicht numerischen Werte das Problem und nicht die numerischen.
Ja, mir ging es mehr ums Prinzip. Also, ob ich den Output beliebig manipulieren kann.
Das ist interessant für HM-Heizkörperventile, dort kann die desired-temp numerisch sein, aber auch "on" oder "off".
Mit der Outputoption könnte man jetzt on/off durch 99/0 ersetzen und die Warnungen vermeiden, die durch numerische Vergleiche entstehen.
Zitat von: Ellert am 23 Februar 2016, 10:31:48
Ja, mir ging es mehr ums Prinzip. Also, ob ich den Output beliebig manipulieren kann.
Das ist interessant für HM-Heizkörperventile, dort kann die desired-temp numerisch sein, aber auch "on" oder "off".
Mit der Outputoption könnte man jetzt on/off durch 99/0 ersetzen und die Warnungen vermeiden, die durch numerische Vergleiche entstehen.
genau, ist doch schön zu sehen, dass die neue Funktionalität durchaus Praxisrelevanz hat :)
Gruß
Damian
ich bin da momentan am probieren aber scheitere leider...!
Irgendwie bin ich da nicht ganz auf der Höhe mit diesen readings.
Könnt ihr da mal einen Blick drauf nehmen in dem Beitrag (http://forum.fhem.de/index.php/topic,49680.msg414353.html#msg414353) habe ich das Problem und das list, ebtl. mal ein Zeile mit dieser neuen Syntax mir auf die Sprünge helfen.
Was ich auch nicht hin bekomme ist das er morgens nach dem hoch fahren, wieder runter fährt weil er wohl den "last_state" benutzt..! :-\
eigentlich funktioniert der Rollladen für meine Terrassentür die ganze Woche über, aber heute weil wohl Samstag ist blieb er wieder mal unten.... ich dachte das Thema wäre erledigt aber leider nicht und ich habe keinen Ansatz wo ich suchen soll... macht er doch am Wochennende das selbe wie in der Woche nur das er etwas später hoch fährt.
Diese Meldungen habe ich im Log, die haben mich bisher auch nicht gestört und sind in der Woche auch nicht so zahlreich, gemeint ist das mit dem "numeric"
2016.03.05 08:29:49 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097753) line 1.
2016.03.05 08:29:49 1: PERL WARNING: Argument "Hoch" isn't numeric in numeric le (<=) at (eval 3097752) line 1.
2016.03.05 08:28:52 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097532) line 1.
2016.03.05 08:28:52 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097526) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097520) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "Runter" isn't numeric in numeric le (<=) at (eval 3097519) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097514) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "Runter" isn't numeric in numeric le (<=) at (eval 3097513) line 1.
2016.03.05 08:28:51 3: CUL_HM set RollladenWZT 100
2016.03.05 08:28:51 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097508) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "set_100" isn't numeric in numeric le (<=) at (eval 3097507) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097502) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "set_100" isn't numeric in numeric le (<=) at (eval 3097501) line 1.
2016.03.05 08:28:51 3: CUL_HM set RollladenWZT 100
2016.03.05 08:28:51 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097496) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "set_100" isn't numeric in numeric le (<=) at (eval 3097495) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097490) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "set_100" isn't numeric in numeric le (<=) at (eval 3097489) line 1.
2016.03.05 08:28:51 3: CUL_HM set RollladenWZT 100
2016.03.05 08:28:51 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097484) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "set_100" isn't numeric in numeric le (<=) at (eval 3097483) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097478) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "set_100" isn't numeric in numeric le (<=) at (eval 3097477) line 1.
2016.03.05 08:28:51 3: CUL_HM set RollladenWZT 100
2016.03.05 08:28:51 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097472) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "set_100" isn't numeric in numeric le (<=) at (eval 3097471) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097466) line 1.
2016.03.05 08:28:51 1: PERL WARNING: Argument "Runter" isn't numeric in numeric le (<=) at (eval 3097465) line 1.
2016.03.05 08:28:49 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097459) line 1.
2016.03.05 08:28:49 1: PERL WARNING: Argument "Runter" isn't numeric in numeric le (<=) at (eval 3097458) line 1.
2016.03.05 08:28:49 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097453) line 1.
2016.03.05 08:28:49 1: PERL WARNING: Argument "Runter" isn't numeric in numeric le (<=) at (eval 3097452) line 1.
2016.03.05 08:28:49 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097446) line 1.
2016.03.05 08:28:49 1: PERL WARNING: Argument "Runter" isn't numeric in numeric le (<=) at (eval 3097445) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097440) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "Runter" isn't numeric in numeric le (<=) at (eval 3097439) line 1.
2016.03.05 08:28:48 3: CUL_HM set RollladenWZT 0
2016.03.05 08:28:48 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097434) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "set_0" isn't numeric in numeric le (<=) at (eval 3097433) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097428) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "set_0" isn't numeric in numeric le (<=) at (eval 3097427) line 1.
2016.03.05 08:28:48 3: CUL_HM set RollladenWZT 0
2016.03.05 08:28:48 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097422) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "set_0" isn't numeric in numeric le (<=) at (eval 3097421) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097416) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "set_0" isn't numeric in numeric le (<=) at (eval 3097415) line 1.
2016.03.05 08:28:48 3: CUL_HM set RollladenWZT 0
2016.03.05 08:28:48 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097410) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "set_0" isn't numeric in numeric le (<=) at (eval 3097409) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097404) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "set_0" isn't numeric in numeric le (<=) at (eval 3097403) line 1.
2016.03.05 08:28:48 3: CUL_HM set RollladenWZT 0
2016.03.05 08:28:48 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097398) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "set_0" isn't numeric in numeric le (<=) at (eval 3097397) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3097392) line 1.
2016.03.05 08:28:48 1: PERL WARNING: Argument "Runter" isn't numeric in numeric le (<=) at (eval 3097391) line 1.
2016.03.05 08:15:09 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3094350) line 1.
2016.03.05 08:15:09 1: PERL WARNING: Argument "Runter" isn't numeric in numeric le (<=) at (eval 3094349) line 1.
2016.03.05 08:15:00 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3094343) line 1.
2016.03.05 08:15:00 3: CUL_HM set RollladenWZT off
2016.03.05 08:15:00 1: PERL WARNING: Argument "off" isn't numeric in numeric le (<=) at (eval 3094335) line 1.
2016.03.05 08:15:00 3: CUL_HM set RollladenWZT on
das ist mein ausführendes DOIF:
([?du_RolloWZmodus] eq "FHEM" and ([[du_RolloZeitWZ_hoch]|8] or [[du_RolloZeitWZ_hoch_WoE]|7])) (set RollladenWZT on)
DOELSEIF ([?du_RolloWZmodus] eq "FHEM" and [WZ_TK_Terrasse:state] eq "closed" and [{sunset("CIVIL",-100,"16:35","22:20")}|78]) (set RollladenWZT off)
DOELSEIF ([?du_RolloWZmodus] eq "FHEM" and [du_Tageslicht] eq "dunkel" and [RollladenWZT] eq "Runter" and [WZ_TK_Terrasse:state] eq "open") ## Wenn Rollladen unten und Terrassentür wird geöffnet
(setreading RollladenWZT last_state [RollladenWZT], set RollladenWZT on,set NI3_LichtTerrasse on) ## schreibe die Position des Rollladen in ein Reading und fahre den Rollladen hoch schalte das Licht Terrasse EIN
DOELSEIF ([?du_RolloWZmodus] eq "FHEM" and [RollladenWZT] <= 100 and [RollladenWZT] eq "open") ## Wenn Rollladen auf einer Position zwischen 0 - 100 und Terrassentür wird geöffnet
(setreading RollladenWZT last_state [RollladenWZT], set RollladenWZT on,set NI3_LichtTerrasse on) ## schreibe die Position des Rollladen in ein Reading und fahre den Rollladen hoch und schalte das Licht Terrasse EIN
DOELSEIF ([?du_RolloWZmodus] eq "FHEM" and [du_Tageslicht] eq "dunkel" and [RollladenWZT:last_state] <= 99 and [WZ_TK_Terrasse:state] eq "closed") ## Wenn das gespeicherte Reading ein Wert von 0 - 99 hat und die Terrassentür wird geschlossen
(set NI3_LichtTerrasse off,set RollladenWZT [RollladenWZT:last_state]) ## nutze das Reading und fahre den Rollladen in die entsprechende Position zurück und schalte das Licht Terrasse AUS
warum funktioniert das nun am WoEnde nicht so wie in der Woche, übersehe ich etwas..?
Zitat([?du_RolloWZmodus] eq "FHEM" and ([[du_RolloZeitWZ_hoch]|8] or [[du_RolloZeitWZ_hoch_WoE]|7])) (set RollladenWZT on)
Das sieht nicht verkehrt aus.
Das letzte DOIF update gab es gestern, also am Besten heute noch updaten und weiter beobachten und "shutdown restart" nicht vergessen.
siehe auch hier: https://forum.fhem.de/index.php/topic,50142.msg419552.html#msg419552
|78 bedeutet jeden Tag, das kannst Du weglassen.
Zitat von: Ellert am 05 März 2016, 21:37:01
Das sieht nicht verkehrt aus.
deshalb ist es mir ja grad unerklärlich, warum der Rollladen am WoEnde unten bleibt oder er wieder runter fährt, werde morgen früh mal schauen.
Seit ich dieses DOIF umgebaut habe mit den ganzen setreadings Werten ist das glaube ich so... gefallen tut mir das alles noch nicht, aber es sollte ja für die kommende Sommerzeit die Beschattung durch führen.
Dann ersetze ich nur "FHEM" durch "Beschattung" weil im Moment brauche ich das ja noch nicht und es ist eine sogenannte Testphase, aber diese klappt eben leider noch nicht. Werde es dann auch in einem eigenen Beschattungs DOIF nutzen, weil es übersichtlicher ist...!
Das ganze fahren des Terrassen Rollladen (RollladenWZT) soll dann bei Beschattung auch funktionieren, damit ist das hoch/runter fahren bei öffnen der Terrassentür gemeint und dann werden die setreadings und last_state Werte genutzt.
Zitat von: moonsorrox am 06 März 2016, 02:07:41
deshalb ist es mir ja grad unerklärlich, warum der Rollladen am WoEnde unten bleibt oder er wieder runter fährt, werde morgen früh mal schauen.
Seit ich dieses DOIF umgebaut habe mit den ganzen setreadings Werten ist das glaube ich so... gefallen tut mir das alles noch nicht, aber es sollte ja für die kommende Sommerzeit die Beschattung durch führen.
Dann ersetze ich nur "FHEM" durch "Beschattung" weil im Moment brauche ich das ja noch nicht und es ist eine sogenannte Testphase, aber diese klappt eben leider noch nicht. Werde es dann auch in einem eigenen Beschattungs DOIF nutzen, weil es übersichtlicher ist...!
Das ganze fahren des Terrassen Rollladen (RollladenWZT) soll dann bei Beschattung auch funktionieren, damit ist das hoch/runter fahren bei öffnen der Terrassentür gemeint und dann werden die setreadings und last_state Werte genutzt.
Dein Ausdruck ist recht komplex, daher Analyse schwierig. Es ist immer tückisch bei vielen Zweigen ohne DOELSE zu arbeiten insb. wenn man kein do always definiert hat. Denn, wenn dein Zustand von cmd_1 nicht zwischendurch in einen anderen wechselt, dann wird logischerweise am nächsten Tag nicht noch mal cmd_1 ausgeführt.
Gruß
Damian
OK, Danke Damian, ich werde mich der ganzen Sache nochmals annehmen und "Neu" aufbauen..! Ich lasse erst einmal das ganze setreadings Gedöns weg ;)
Danach werde ich mir ein komplette Beschattungssteuerung mit Temperatur, Helligkeit, Beschattungsendzeit usw. aufbauen...
Hallo ist es mitterweile möglich in dEM Beispiel:
(Bedingun) (Event1) (Event2)
Das das Event2, wiederholt wird? Würde gerne ein Event 8 mal wiederholen.
Das funktioniert nur für alle Befehle/Sequenzen eines Bedingungszweiges, s. https://fhem.de/commandref_DE.html#DOIF_repeatcmd
Zitat von: Tueftler1983 am 12 Februar 2017, 23:35:10Würde gerne ein Event 8 mal wiederholen.
([was auch immer])(Befehl_1,set $SELF cmd_2)
DOELSEIF (false)(Befehl_2)
attrib XXX repeatcmd 0:20
attrib XXX repeatsame 1:8
Das Problem ist das in meinem DOIF 4 Events ausgeführt werden sollen von den das 4. Neun mal wiederholt werden muss mit jeweils 1 sek verzögerung. Derzeit sieht es so aus
([d_Wecker] eq "on" and [[d_Weckzeit:state]]) (set d_HitRadio on) (set d_Soundbar POWER) (set ledstrip GREEN) (set ledstrip BRIGHTER) (set ledstrip BRIGHTER) (set ledstrip BRIGHTER)(set ledstrip BRIGHTER) (set ledstrip BRIGHTER) (set ledstrip BRIGHTER) (set ledstrip BRIGHTER) (set ledstrip BRIGHTER) (set ledstrip BRIGHTER)
Mit dem Attribut wait 0,0,0,1,1,1,1,1,1,1,1
Wo ist das Problem?
([d_Wecker] eq "on" and [[d_Weckzeit:state]]) (set d_HitRadio on,set d_Soundbar POWER,set ledstrip GREEN,set $SELF cmd_2)
DOELSEIF (0) (set ledstrip BRIGHTER)
repeatcmd 0:1
repeatsame 1:8
Hm. Wenn ich jetzt nur das einzelne Kommando set nasBackupHD on (und nur dieses) mehrmals hintereinander senden wollen würde, müsste ich ihm (also nur diesem Kommando) ein eigenes DOELSEIF spendieren, richtig?
([14:59|Do]) (setreading $SELF doifState reset)
DOELSEIF ([15:00-24:00|Do] and [Bewohner:"home"]) (setreading $SELF doifState hd_startup, set nasBackupHD on, set doif_NAS disable)
DOELSEIF ([?$SELF:doifState] eq "hd_startup") (set doif_NAS enable, setreading $SELF doifState hd_finished, set nasBackupHD off)
Gruß Chris
Ja, aber du musst auch selftrigger anschalten mit ? wird dein dritter Fall nie (!) angetriggert.
Wenn du das ? hingegen wegnimmst, musst du hoffen, dass auch "set nasBackupHD on, set doif_NAS disable" irgendwann mal ausgeführt wird, denn du verlässt ja den zweiten Fall, bevor er zu Ende ist.
Ich möchte die Abfrage der Luftfeuchtigkeit realisieren und eine Warnung geben wenn sie über einem bestimmten Wert ist. Es funktioniert einigermaßen mit:
([TH_Variabel:humidity] > "60") ({
my $hum = ReadingsVal("TH_Variabel","humidity","");;
Log 1, "Hohe Luftfeuchtigkeit im Schlafzimmer";;
fhem("set pushmsg msg title='Schlafzimmer' message='$hum% Luftfeuchtigkeit!'");;
})
DOELSE)
Der Lacrosse Sensor TH_Variabel gibt die Luftfeuchtigkeit ziemlich häufig aus, daher wird man sehr zugespamt mit Nachrichten. Ich habe es nun mit
attr xxx repeatcmd 3600
probiert, mit dem Gedanken, dass ich bei Auslösung des DOIF eine Nachricht bekomme und falls nach einer Stunde immer noch hum > 60 % noch eine.
Es will aber noch nicht richtig klappen. Es wirkt eher so als wenn die DOIF Abfrage jede Stunde durch geführt wird und schaut ob die Bedingung korrekt ist.
Ist das so richtig und ich hab lediglich den Befehl flasch verstanden? Oder ist irgendwo ein Fehler drin?
Ich habe auch
attr xxx do always
mit eingebaut, auch wenn ich mir nicht 100% sicher bin ob das notwendig ist (hatte es in einem Beispiel in der commandref so gesehen)
Edit: Irgendwie ist definitiv der Wurm drin. Wenn ich repeatcmd lösche löst er jetzt gar nicht mehr aus, auch wenn ich die Bedingung auf einen wahren Wert wie z.b. > "40" setze
Es scheint irgendwie die Befehlsausführung jede Stunde gespeichert zu sein. Es kam jetzt nochmal eine Meldung. Also scheint repeatcmd dafür zu sorgen, das DOIF alle in repeatcmd angegebenen Sekunden zu prüfen ob die Bedingung stimmt.
Eine Funktion mit der er direkt bei Erüllung der DOIF-Bedingung auslöst und dann aber frühestens wieder in z.B. einer Std., falls die Bedingung immer noch erfüllt ist, gibt es nicht, oder?
Wahrscheinlich sucht du so etwas: https://fhem.de/commandref_DE.html#DOIF_cmdpause
Hm, ja das hatte ich anfangs probiert, war jedoch nicht erfolgreich. Ich bekomme grade nicht mehr ganz zusammen was dabei passiert ist.
Aktuell verstehe ich aber generell nicht was los ist. Ich habe alle betreffenden Attribute wieder gelöscht, aber das DOIF reagiert nicht (s. Screenshot). Wenn ich FHEM neustarte wird es einmal ausgelöst, aber das war es dann.
Edit: Irgendwie werden die readings nicht geupdated, obwohl der Sensor alle paar Sekunde neue Werte liefert (deutlich über 40% humidity)
Eventuell ein neues Userreading definieren, was unterhalb des Werts z.B. auf false und oberhalb von 60 auf true gesetzt wird.
Und dieses Userreading sollte bei event-on-change mit enthalten sein.
Das sollte sich dann nicht mehr ändern, auch wenn der Wert auf 70 oder 80 steigt.
Dann kannst du auf diesem Userreading das DOIF ansetzen und bekommst nur eine Meldung.
Ich würde bei dem sensor schon mit event-on-change arbeiten, um die Ebene Flut einzudämmen. Bei Daten die regelmäßig kommen brauchst eigentlich kein do always.
Gruß Sascha
Besten Dank an alle!
Zitat von: jhohmann am 01 Februar 2023, 18:13:25
Eventuell ein neues Userreading definieren, was unterhalb des Werts z.B. auf false und oberhalb von 60 auf true gesetzt wird.
Dieser Tipp hat letztlich zum Erfolg geführt.
Tatsächlich hab ich aktuell nun noch das Problem, das die Sensorausgabe tendenziell etwas schwankt. Das heißt, dass er beim Übergang von 59,9% auf 60% ab und zu hin und her springt. Das bringt mir dann jedes Mal eine Push-Nachricht aufs Handy.
Ich hätte nun gedacht, dass der cmdpause Befehl genau das Problem lösen sollte. Wenn ich aber z.B. cmdpause mit 600 Sek. nutze löst das DOIF überhaupt nicht mehr aus. Auch wenn ich den Schwellwert in meinem Userreading händisch ein paar mal ändere, 30% --> 60% --> 30% usw.
Das Reading springt dann von true auf false usw. aber das DOIF bleibt stumm.
Habe ich da einen Denkfehler?
Nimm event-on-change-reading. Da kannst du auch festlegen, wann ein Event ausverkauft werden soll. Z.b. Wenn sich das angegebene reading um 0.2 oder 0.4 ändert, wie bei Temperatur oder was auch immer
Hatte jetzt erst gedacht das es nicht funktioniert weil ich
attr DOIF_hum do alwaysnicht gesetzt hatte. Aber das hat auch nicht wirklich was geändert. Das DOIF hat einmal ausgelöst, aber wenn ich Schwellwert wieder rauf und nach Ablauf des Werts von cmdpause wieder runter gesetzt habe hat das DOIF nicht mehr ausgelöst.
Zitat von: sash.sc am 08 Februar 2023, 14:50:54
Nimm event-on-change-reading. Da kannst du auch festlegen, wann ein Event ausverkauft werden soll. Z.b. Wenn sich das angegebene reading um 0.2 oder 0.4 ändert, wie bei Temperatur oder was auch immer
Interessanter Ansatz, ich denke ich versteh erst jetzt was du meinst, sorry, du hattest den Hinweis ja schon vorher gegeben. Tatsächlich wird die Luftfeuchtigkeit nur in ganzen Zahlen ausgegeben (das hatte ich falsch im Kopf). Also wäre jetzt der Ansatz beim Sensor das Attribut zu setzen
attr DTH_Sensor event-on-change-reading humidity:1,.*Ich habe event-on-change-reading bei den meisten Geräten standardmäßig auf .*
Nachteil wäre jetzt, dass ich nun künstlich die Genauigkeit des Sensors für Luftfeuchtigkeit verschlechtert habe, oder? So richtig ideal wäre das ja auch noch nicht, oder hab ich da noch was falsch verstanden? Und noch eine Verständnisfrage, die meines Erachtens nicht aus der Referenz hervorgeht: Muss eine einzelne Änderung größer sein als der Schwellwert in event-on-change-reading? Dann würde er bei nie auslösen wenn nur Änderungen < Schwellwert auftreten? Oder summiert er? Aber ab wann zählt er dann?
Prinzipiell vestehe ich aber auch immer noch nicht wieso es mit cmdpause nicht funktioniert, da es laut commandref ja genau meine Anwendung abbilden sollte (https://fhem.de/commandref_DE.html#DOIF_cmdpause):
Zwangspause für das Ausführen eines Kommandos seit der letzten Zustandsänderung
Mit dem Attribut cmdpause <Sekunden für cmd_1>:<Sekunden für cmd_2>:... wird die Zeitspanne in Sekunden angegeben für eine Zwangspause seit der letzten Zustandsänderung. In der angegebenen Zeitspanne wird ein Kommando nicht ausgeführt, auch wenn die dazugehörige Bedingung wahr wird.
Anwendungsbeispiel: Meldung über Frostgefahr alle 60 Minuten
define di_frost DOIF ([outdoor:temperature] < 0) (set pushmsg "danger of frost")
attr di_frost cmdpause 3600
attr di_frost do always
Oder andere Herangehensweise.
Ist es möglich im Userreading eine Abfrage der folgenden Art zu machen:
if Luftf. > 60 = true
elif Luftf. <= 58 = false
else = vorheriger bool Wert bleibt bestehen