Hauptmenü

neues Modul DOIF

Begonnen von Damian, 21 Mai 2014, 15:53:18

Vorheriges Thema - Nächstes Thema

cruser1800

Hallo Damain,

das Ereignis war da. Heißt das, dass meine Fritzbox zu lange für die Bearbeitung des cmd_2 benötigt, so dass schon  vor Bearbeitung der wait_timer gesetzt wird?

Dann sollte ich mir wohl eine andere Lösung als Server suchen!

Danke
Lutz

Damian

Zitat von: cruser1800 am 15 Juli 2014, 21:23:45
Hallo Damain,

das Ereignis war da. Heißt das, dass meine Fritzbox zu lange für die Bearbeitung des cmd_2 benötigt, so dass schon  vor Bearbeitung der wait_timer gesetzt wird?

Dann sollte ich mir wohl eine andere Lösung als Server suchen!

Danke
Lutz

Verstehe ich nicht. Der Timer wurde doch maximal eine Sekunde nach dem Event gesetzt (20:08:19) und nicht davor???

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

cruser1800

#227
Zitat von: Damian am 15 Juli 2014, 21:28:29
Verstehe ich nicht. Der Timer wurde doch maximal eine Sekunde nach dem Event gesetzt (20:08:19) und nicht davor???

Gruß

Damian

Die Helligkeit hat den Wert unterschritten, so dass cmd_1 nicht eintritt und cmd_2 hätte ausgeführt werden müssen.

Leider wurde aber cmd_2 nicht ausgeführt sondern der wait_timer aktiviert. Somit wurde die erste Ausführung von cmd_2 erst nach der Wartezeit von 15 min aktiviert.

Da ich Jalousien damit steuere ist es 15 min länger dunkel.

Hier noch der Auszug aus dem Journal.

2014-07-15_19:02:12 Verschattung_WZ cmd_1
2014-07-15_19:02:12 Verschattung_WZ last_cmd: 1
2014-07-15_19:02:12 Verschattung_WZ last_cmd_event: 001_Wetterstation
2014-07-15_19:02:12 Verschattung_WZ last_error: no error
2014-07-15_19:02:12 Verschattung_WZ next_wait_timer: no wait_timer
2014-07-15_20:08:19 Verschattung_WZ next_wait_timer: 15.07.2014 20:23:19 cmd_2 001_Wetterstation
2014-07-15_20:23:19 Verschattung_WZ cmd_2
2014-07-15_20:23:19 Verschattung_WZ last_cmd: 2
2014-07-15_20:23:19 Verschattung_WZ last_cmd_event: 001_Wetterstation
2014-07-15_20:23:19 Verschattung_WZ last_error: no error
2014-07-15_20:23:19 Verschattung_WZ next_wait_timer: no wait_timer

Da sieht man auch, dass erst der Timer gesetzt wird und beim nächsten mal das cmd_2 ausgeführt wird.


Gruß

Lutz

Damian

Zitat von: cruser1800 am 15 Juli 2014, 21:33:41
Die Helligkeit hat den Wert unterschritten, so dass cmd_1 nicht eintritt und cmd_2 hätte ausgeführt werden müssen.

Leider wurde aber cmd_2 nicht ausgeführt sondern der wait_timer aktiviert. Somit wurde die erste Ausführung von cmd_2 erst nach der Wartezeit von 15 min aktiviert.

Da ich Jalousien damit steuere ist es 15 min länger dunkel.

Gruß

Lutz

Wie sieht denn die Definition des Wait-Attributes aus, sonst kann ich nur raten.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

cruser1800

Zitat von: Damian am 15 Juli 2014, 21:37:57
Wie sieht denn die Definition des Wait-Attributes aus, sonst kann ich nur raten.

Gruß

Damian

wait           900:900

Damian

#230
Zitat von: cruser1800 am 15 Juli 2014, 21:41:58
wait           900:900

Es funktioniert wie programmiert. Mit wait 900:900 hast du definiert, dass er 15 Minuten warten solle bevor er das Kommando ausführt und genau das tut er auch.

Warum sollte er denn das Kommando cmd_2 um 20:08:18 ausführen, wenn du ihm sagst, dass er 15 Minuten nach dem Erfüllen der Bedingung (hier für cmd_2) warten soll.

Da hast du offenbar etwas missverstanden.

Gruß

Damian


Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

cruser1800

Zitat von: Damian am 15 Juli 2014, 21:49:06
Es funktioniert wie programmiert. Mit wait 900:900 hast du definiert, dass er 15 Minuten warten solle bevor er das Kommando ausführt und genau das tut er auch.

Warum sollte er denn das Kommando cmd_2 um 20:23:18 ausführen, wenn du ihm sagst, dass er 15 Minuten nach dem Erfüllen der Bedingung (hier für cmd_2) warten soll.

Da hast du offenbar etwas missverstanden.

Gruß

Damian




Danke, wieder etwas dazu gelernt! Ich bin davon ausgegangen, dass er erst ausführt und dann bei erneuten  Ergebnis erst eine definierte Pause abwartet.

Ist hier genau andersrum!

Danke

Lutz

Damian

Zitat von: cruser1800 am 15 Juli 2014, 21:52:15
Danke, wieder etwas dazu gelernt! Ich bin davon ausgegangen, dass er erst ausführt und dann bei erneuten  Ergebnis erst eine definierte Pause abwartet.

Ist hier genau andersrum!

Danke

Lutz

ja. Wichtig zu wissen ist noch, wenn der Zustand während der Wartezeit für cmd_2 sich ändert, bei dir also auf cmd_1, dann wird der Timer von cmd_2 wieder zurückgesetzt und der Timer für cmd_1 gesetzt. Das würde z. B. bedeuten, wenn im Takt von unter 15 Minuten der Zustand bei dir wechseln würde, dann würde nie geschaltet.

So etwas kann man auch mit Watchdog erreichen und genau das wollte ich bei DOIF auf eine einfache Weise auch haben.

Eine definierte Zwangspause, kannst du mit event-min-interval als Attribut bei dem jeweiligen Device definieren.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

satprofi

Zitat von: Damian am 15 Juli 2014, 21:05:19
Nein.

An welchen Werten? Es wird immer nur einmal geschaltet, bis sich der Zustand ändert, wenn du do always nicht angibst.

Wenn man Änderungen an der Definition (DEF) vornimmt, werden alle Werte zurückgesetzt, dann sollte das nächste zutreffende Event das entsprechenden Kommando auslösen.

Für irgendwelche Analysen, musst du mir einen nachvollziehbaren Fall liefern.

Gruß

Damian

ich habe nur den temperaturwert geändert. danach kam nichts mehr, obwohl ja die temperatur zu hoch war.

liegts jetzt an "do always" ? das hab ich aktiviert.
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

Damian

Zitat von: satprofi am 16 Juli 2014, 18:18:01
ich habe nur den temperaturwert geändert. danach kam nichts mehr, obwohl ja die temperatur zu hoch war.

liegts jetzt an "do always" ? das hab ich aktiviert.

Poste mal deine Definition, dann kann ich dir sagen, ob die Sache sinnvoll ist. Vielleicht ist es nur ein Verständnisproblem.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Damian

#235
Vorab zur Info

Ich bin in der Testphase einer neuen Version, die nun auch mit Zeitintervallen umgehen kann. Ich habe auch gleich eine Wochentagfunktion eingebaut, weil ich die Wochentag-Abfragen umständlich fand. Hier einige Beispiele aus der neuen Doku:

Radio soll zwischen 8:00 und 10:00 Uhr an sein:

define DI_Radio DOIF ([08:00-10:00]) (set Radio on) DOELSEIF (set Radio off)

Nur sonntags (0) und samstags (6) (1 entspricht Montag, 2 Dienstag, usw. 5 Freitag):

define DI_Radio DOIF ([08:00-10:00]|06) (set Radio on) DOELSEIF (set Radio off)

Nur montags, mittwochs und freitags:

define DI_Radio DOIF ([08:00-10:00]|135) (set Radio on) DOELSEIF (set Radio off)

Nur am Wochenende bzw. an Feiertagen lt. holiday-Datei (7 entspricht $we):

define DI_Radio DOIF ([08:00-10:00]|7) (set Radio on) DOELSEIF (set Radio off)

Nur an Arbeitstagen (8 ist das Gegenteil von 7, entspricht !$we):

define DI_Radio DOIF ([08:00-10:00]|8) (set Radio on) DOELSEIF (set Radio off)


Schalten bei Sonnenaufgang und Sonnenuntergang:

define DI_Licht ([{sunrise_abs()}-{sunset_abs()}]) (set Aussenleuchte off) DOELSEIF (set Aussenleuchte on)

Rollläden sollen an Arbeitstagen nach 6:25 Uhr hochfahren, wenn es hell wird, am Wochenende erst um 9:00 Uhr:

define DI_Rolladen DOIF ([Sensor:helligkeit]>100 and [06:25-09:00|8] or [09:00|7]) (set Rollladen on)


Wenn die Tests erfolgreich abgeschlossen sind, gibt´s natürlich eine Info zum Download.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

joshi04

Das Modul ist schon super und es wird immer besser! Vorweg ein großer Dank auch wenn sichs wiederholt.
Die Nomenklatur der Tage ist beim Heatung_Control schon ziemlich "sufisticated". Vielleicht kannst Du etwas übernehmen. Aber es gibt sicher Gründe, warum das nicht direkt geht und ich finds  schon total klasse, wenns überhaupt geht. Nomenklatur ist ja nur einmal bei der Definition wichtig.

Ich stelle mich gerne zum testen zur Verfügung.
Schöne Grüße,
John


Gesendet von meinem iPhone mit Tapatalk
NUC: 2xJeeLink, PCA301/TX35DTH; HueBridge, LivingColors; vair-monitor (CO2); HMLan, Winmatic, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-ES-TX-WM, HM-WDS10-TH-O, HM-ES-PMSw1-Pl, HM-SEC-SC-2, HM-SEC-SCo; AVM DECT 200; panStamp; smartVISU

Brockmann

Zitat von: Damian am 16 Juli 2014, 22:16:32
Ich bin in der Testphase einer neuen Version, die nun auch mit Zeitintervallen umgehen kann. Ich habe auch gleich eine Wochentagfunktion eingebaut, weil ich die Wochentag-Abfragen umständlich fand. Hier einige Beispiele aus der neuen Doku:
Wäre es prinzipiell auch möglich, ein "offenes" Intervall anzugeben. Für den Anwendungsfall, den ich hier schon mal geschildert hatte: Ein Licht soll bei Sonnenuntergang, aber frühestens 17:00 Uhr angeschaltet werden. Wenn der Sonnenuntergang vor 17:00 Uhr liegt, soll eben erst um 17:00 Uhr geschaltet werden.

Theoretisch also:
DOIF ([{sunset_abs()}] and [17:00-]) (set Licht on) DOELSE (set Licht off)
aber praktisch geht das vermutlich nicht? Das Problem bei diesem Szenario ist, dass das Licht nicht zu einem bestimmten Zeitpunkt wieder ausgeschaltet werden soll, sondern über eine andere Funktion beim "ins Bett gehen" ausgeschaltet wird.

Wobei, wenn ich die richtig verstehe, könnte ich mir beispielsweise hiermit behelfen:
DOIF ([{sunset_abs()}] and [17:00-sunrise_abs()}]) (set Licht on) DOELSE (set Licht off)
Wobei sunrise_abs erst am nächsten Tag liegt und kleiner als 17:00 Uhr ist. Das reale Intervall wäre also beispielsweise heute 17:00-04:39:59. Würde DOIF damit in diesem Szenario wie gewünscht funktionieren?

Damian

Zitat von: Brockmann am 17 Juli 2014, 06:47:16
Wäre es prinzipiell auch möglich, ein "offenes" Intervall anzugeben. Für den Anwendungsfall, den ich hier schon mal geschildert hatte: Ein Licht soll bei Sonnenuntergang, aber frühestens 17:00 Uhr angeschaltet werden. Wenn der Sonnenuntergang vor 17:00 Uhr liegt, soll eben erst um 17:00 Uhr geschaltet werden.

Theoretisch also:
DOIF ([{sunset_abs()}] and [17:00-]) (set Licht on) DOELSE (set Licht off)
aber praktisch geht das vermutlich nicht? Das Problem bei diesem Szenario ist, dass das Licht nicht zu einem bestimmten Zeitpunkt wieder ausgeschaltet werden soll, sondern über eine andere Funktion beim "ins Bett gehen" ausgeschaltet wird.

Wobei, wenn ich die richtig verstehe, könnte ich mir beispielsweise hiermit behelfen:
DOIF ([{sunset_abs()}] and [17:00-sunrise_abs()}]) (set Licht on) DOELSE (set Licht off)
Wobei sunrise_abs erst am nächsten Tag liegt und kleiner als 17:00 Uhr ist. Das reale Intervall wäre also beispielsweise heute 17:00-04:39:59. Würde DOIF damit in diesem Szenario wie gewünscht funktionieren?

Offene Intervalle sind schwierig, sie enden um Mitternacht. Wenn sie nicht enden würden, dann kann man gleich einen Zeitpunkt wählen.

Intervalle z. B. [17:00-16:00] oder mit Funktionen werden unterstützt.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Brockmann

Zitat von: Damian am 17 Juli 2014, 07:45:26
Intervalle z. B. [17:00-16:00] oder mit Funktionen werden unterstützt.
Nur noch mal zur Sicherheit:
Das heisst, wenn bei einem Intervall die zweite Angabe kleiner als die erste ist, wird der zweite Zeitpunkt auf den nächsten Tag verschoben?
[17:00-04:00] wäre also zwischen 17:00 Uhr abends heute und 4:00 Uhr morgens am nächsten Tag wahr?