neues Modul DOIF

Spartacus · 31 Dezember 2014, 10:30:32

Hallo Damian,
super! Danke. Dann muss ich jetzt noch ein Jahr warten.....

Parallel habe ich Deinen Vorschlag mit Sequence und dem Dummy ausprobiert. Aber da baue ich dann ein schönes Blinklicht. Das funktioniert leider nicht so, wie ich mir das vorgestellt habe....

Code Auswählen

define sKurzerLangerDruck_UR sequence PTM210.Gira.01:BI 0.5 PTM210.Gira.01:buttons:.released
attr sKurzerLangerDruck_UR triggerPartial 1
...
define nLangerDruck_UR notify sKurzerLangerDruck_UR:partial_1 set LangDruck on
---
define LangDruck dummy

und dann das DOIF:

Code Auswählen

define diEingangsLicht DOIF (([EG.ss.TK.Haustuer:buttons] eq "pressed" or [EG.ss.LS.Eingang:buttons] eq "pressed") and [?rp.02.EG.ku.SD.Kochinsel] eq "off") \
	(set rp.02.EG.ku.SD.Kochinsel on)\
DOELSEIF ([LangDruck] eq "on" and [rp.02.EG.ku.SD.Kochinsel] eq "off") \
	(set rp.02.EG.ku.SD.Kochinsel on)\
DOELSEIF ([EG.ss.TK.Haustuer:buttons] eq "released" and [EG.ss.LS.Eingang:buttons] eq "released" and [rp.02.EG.ku.SD.Kochinsel] eq "on" and [diEingangsLicht] eq "sensor_on") \
	(set rp.02.EG.ku.SD.Kochinsel off)\
DOELSEIF ([LangDruck] eq "on" and [rp.02.EG.ku.SD.Kochinsel] eq "on")\
	(set rp.02.EG.ku.SD.Kochinsel off)
attr diEingangsLicht cmdState sensor_on|manual_on|sensor_off|manual_off
attr diEingangsLicht wait 0:0:10:0

Wenn ich LangDruck gegen

Code Auswählen

[PTM210.Gira.01:state] eq "A0" ersetze funzt es wie es soll.
Irgendwie muss das Dummy wieder auf "released" sonst klappt das austasten nicht...
Christian.

Papaloewe · 31 Dezember 2014, 10:36:16

@Spartatcus
Schau mal du hast "Silverster" und nicht "Silvester" geschrieben.

maxritti · 31 Dezember 2014, 11:28:11

Zitat von: Papaloewe am 31 Dezember 2014, 10:36:16
@Spartatcus
Schau mal du hast "Silverster" und nicht "Silvester" geschrieben.

Der Schreibfehler ist ein Folgefehler.

Steht nämlich auch so in seiner Holiday Datei drin.

http://forum.fhem.de/index.php/topic,30861.msg234256.html#msg234256

Spartacus · 31 Dezember 2014, 13:05:04

Hallo zusammen,
habe den Fehler korrigiert. Zufall, dass ich es durchgängig falsch geschrieben hatte...
Danke und Gruß,
Christian

raimundl · 01 Januar 2015, 14:41:09

Hallo und Danke für all die Möglichkeiten.
Erste Schritte getan, Anwendung funktioniert - trotzdem die Bitte einen Blick darauf zu werfen:

Was:
Anwesenheitssimulation (wenn Handy Nexus4 absent) durch Einschalten einer Beleuchtung mit Verständigung über Pushover ab "sunset" bis zu einer bestimmten Uhrzeit.

Wie (aus fhem.cfg):
define nichtda DOIF ([{sunset("REAL",0,"15:00","22:00")}-23:00] and ([Nexus4] eq "absent")) (set EG_Decke02 on-till 23:09:50, set Pushover1 msg 'Titel' 'Anwesenheitssimulation' '' 0 '')\

Frage:
Wieso wird bei "sunset" und "absent" der Befehl für die Einschaltung der Beleuchtung und die Verständigung zweimal (Abstand ca. 1 Minute) ausgeführt:

2014-12-31_16:03:35 EG_Decke02 set_on-till 23:09:50
2014-12-31_16:03:36 EG_Decke02 level: 100
2014-12-31_16:03:36 EG_Decke02 pct: 100
2014-12-31_16:03:36 EG_Decke02 deviceMsg: on (to CUL0)
2014-12-31_16:03:36 EG_Decke02 on
2014-12-31_16:03:36 EG_Decke02 timedOn: running
2014-12-31_16:05:20 EG_Decke02 set_on-till 23:09:50
2014-12-31_16:05:22 EG_Decke02 level: 100
2014-12-31_16:05:22 EG_Decke02 pct: 100
2014-12-31_16:05:22 EG_Decke02 deviceMsg: on (to CUL0)
2014-12-31_16:05:22 EG_Decke02 on
2014-12-31_16:05:22 EG_Decke02 timedOn: running

Die Funktion ist dadurch nicht gestört!

LG

Edit: Heute mit "sunset_abs()" probiert - auch zweimal ausgeführt. Es dürfte jeweils mit neuem "sunset-Zeitpunkt" zu tun haben (jeden Tag jetzt ca. 1 Min. später)?

Sidey · 01 Januar 2015, 20:34:30

Hallo,

da ich mit meinen Notifys und AT Befehlen ein paar Schwierigkeiten bei der richtigen Abfolge meiner Befehle hatte, bin ich dabei auf das tolle DOIF Modul um zu steigen.

Es gefällt mir sehr gut und vereinfacht die Sache auch enorm aus meiner Sicht.

Ein kleine kleines Problem habe ich allerdings mit einer Uhrzeit die in einem Dummy gespeichert ist:

Code Auswählen

define wk.Waschzeit_change dummy
attr wk.Waschzeit_change icon icoUhr
attr wk.Waschzeit_change room Waschkeller
attr wk.Waschzeit_change setList state:time
attr wk.Waschzeit_change userReadings update {return 1}
attr wk.Waschzeit_change webCmd state

In dem Dummy speichere ich die Zeit, wann die Waschmaschine laufen soll.
Ich habe ein userReading "update" angelegt, damit ich im doif darauf eine Bedingung setzen kann

Die ensprechende DOIF Anbrage läuft dann erst mal auf das UserReading mit dem Namen "update" und die Zeit hole ich über die Perl Funktion ReadingsVal.

Code Auswählen


DOELSEIF ([wk.Waschzeit_change:update]>0 && [{ReadingsVal("wk.Waschzeit_change","state","00:00")}] && [wk.WaschmaschineWartemodus] eq "on" ) (set wk.WaschmaschineWartemodus off,set wk.Waschmaschine_Betrieb on,set wk.PwrSw_Switch on)

Ich hatte gehofft, dass die Uhrzeit durch das Prüfung auf das userReading bei jedem Ändern der Uhrzeit im dummy Waschzeit_change geändert wird. Leider klappt das aber nicht.

Wie könnte ich das bewerkstelligen, dass die Uhrzeit in der DOIF aktualisiert wird?

Grüße Sidey

maxritti · 01 Januar 2015, 20:59:24

Hi Sidey,

schau mal hier (Punkt 4), da habe ich das auch realisiert:

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

Du musst ein zusätzliches DOIF definieren, welches auf Änderungen Deiner Uhrzeit in dem Dummy wk.Waschzeit_change reagiert und dann die Definition deines DOIFs neu schreibt.

Sidey · 01 Januar 2015, 22:51:51

Hi Maxritti,

hatte schon gedacht, dass es die Fragestellung schon mal gab, es aber einfach nicht gefunden.
Danke dir. So was in der Art habe ich schon mal über ein Notify gemacht. Aber das Notify kommt nicht auf das Internal so einfach wie das DOIF, verstehe jetzt wieso Du das verwendet hast.

Ich habe nun ein wenig gerätselt, wieso

Code Auswählen

modify wk.Waschmaschine_DI {InternalVal("wk.Waschmaschine_DI","DEF","")}

nicht geht, aber keine Antwort gefunden. Wenn die Zeile so gehen würde, dann könnte man die ja in das dummy als userReading einbauen.

Code Auswählen

define wk.WamaSetTime DOIF ([wk.Waschzeit_change]) (modify wk.Waschmaschine_DI [wk.Waschmaschine_DI:&DEF])

aktualsiert das DOIF "wk.Waschmaschine_DI"

Allerdings wird der Abschnitt ReadingsVal nicht durch die Zeit ersetzt, wüsste auch nicht wieso.
Das ginge doch nur, wenn ich ReadingsVal in eine Variable speichere und dann an dieser Stelle den Wert der Varialble einsetze oder?

Grüße Sidey

maxritti · 01 Januar 2015, 23:13:56

Hi,

ich verstehe jetzt nicht ganz, auf was Du raus willst?
Klappt das nicht mit dem DOIF, welches auf die Änderung in Deinem Zeitdummy reagiert und die DEF des anderen DOIFs ändert?

Zitat von: Sidey am 01 Januar 2015, 22:51:51
Allerdings wird der Abschnitt ReadingsVal nicht durch die Zeit ersetzt, wüsste auch nicht wieso.
Das ginge doch nur, wenn ich ReadingsVal in eine Variable speichere und dann an dieser Stelle den Wert der Varialble einsetze oder?

Grüße Sidey

Es braucht auch nicht wirklich etwas ersetzt werden. Denn genau das wäre ja falsch, so wie es in der letzten Version war.

Es geht darum, dass das DOIF intern Timer verwendet um zu den gewünschten Zeitpunkten zu reagieren.
Diese werden mMn bei der Initialisierung des DOIFs gesetzt und können mit dem modify bewusst aktualisiert werden.

Damian · 01 Januar 2015, 23:22:14

Zitat von: raimundl am 01 Januar 2015, 14:41:09
Hallo und Danke für all die Möglichkeiten.
Erste Schritte getan, Anwendung funktioniert - trotzdem die Bitte einen Blick darauf zu werfen:

Was:
Anwesenheitssimulation (wenn Handy Nexus4 absent) durch Einschalten einer Beleuchtung mit Verständigung über Pushover ab "sunset" bis zu einer bestimmten Uhrzeit.

Wie (aus fhem.cfg):
define nichtda DOIF ([{sunset("REAL",0,"15:00","22:00")}-23:00] and ([Nexus4] eq "absent")) (set EG_Decke02 on-till 23:09:50, set Pushover1 msg 'Titel' 'Anwesenheitssimulation' '' 0 '')\

Frage:
Wieso wird bei "sunset" und "absent" der Befehl für die Einschaltung der Beleuchtung und die Verständigung zweimal (Abstand ca. 1 Minute) ausgeführt:

2014-12-31_16:03:35 EG_Decke02 set_on-till 23:09:50
2014-12-31_16:03:36 EG_Decke02 level: 100
2014-12-31_16:03:36 EG_Decke02 pct: 100
2014-12-31_16:03:36 EG_Decke02 deviceMsg: on (to CUL0)
2014-12-31_16:03:36 EG_Decke02 on
2014-12-31_16:03:36 EG_Decke02 timedOn: running
2014-12-31_16:05:20 EG_Decke02 set_on-till 23:09:50
2014-12-31_16:05:22 EG_Decke02 level: 100
2014-12-31_16:05:22 EG_Decke02 pct: 100
2014-12-31_16:05:22 EG_Decke02 deviceMsg: on (to CUL0)
2014-12-31_16:05:22 EG_Decke02 on
2014-12-31_16:05:22 EG_Decke02 timedOn: running

Die Funktion ist dadurch nicht gestört!

LG

Edit: Heute mit "sunset_abs()" probiert - auch zweimal ausgeführt. Es dürfte jeweils mit neuem "sunset-Zeitpunkt" zu tun haben (jeden Tag jetzt ca. 1 Min. später)?

Dein Modul wird zu Beginn und zum Ende des Zeitintervalls getriggert und jedesmal, wenn Nexus4 etwas sendet. Das Zeitintervall ist von sunset bis 23:00 Uhr wahr. D. h. wenn Nexus4 um 16:03:35 "absent" war, dann wird set ausgeführt und immer dann wenn nexus4 zwischen sunset und 23:00 Uhr sich meldet und "absent" ist, hier offenbar um 16:05:20.

Gruß

Damian

raimundl · 02 Januar 2015, 08:31:56

Zitat von: Damian am 01 Januar 2015, 23:22:14
Dein Modul wird zu Beginn und zum Ende des Zeitintervalls getriggert und jedesmal, wenn Nexus4 etwas sendet. Das Zeitintervall ist von sunset bis 23:00 Uhr wahr. D. h. wenn Nexus4 um 16:03:35 "absent" war, dann wird set ausgeführt und immer dann wenn nexus4 zwischen sunset und 23:00 Uhr sich meldet und "absent" ist, hier offenbar um 16:05:20.

Gruß

Damian

Hallo Damian!

Ich glaube den Grund für das (richtige) Verhalten gefunden zu haben:

"sunset" ist zum Beispiel am 29.12.2014 um 16:35 - bei erreichen dieser Zeit und Nexus4 "absent" wird die Bedingung wahr. Dann jedoch springt "sunset" sofort auf die Zeit vom nächsten Tag, das ist derzeit ca. 2 Min. später, also 16:37 am 30.12.2014 und die Bedingung wird wieder wahr. Daher das zweimalige Schalten. Das Datum wird ja beim Zeitvergleich nicht berücksichtigt?

Danke und LG

Damian · 02 Januar 2015, 09:12:18

Zitat von: raimundl am 02 Januar 2015, 08:31:56
Hallo Damian!

Ich glaube den Grund für das (richtige) Verhalten gefunden zu haben:

"sunset" ist zum Beispiel am 29.12.2014 um 16:35 - bei erreichen dieser Zeit und Nexus4 "absent" wird die Bedingung wahr. Dann jedoch springt "sunset" sofort auf die Zeit vom nächsten Tag, das ist derzeit ca. 2 Min. später, also 16:37 am 30.12.2014 und die Bedingung wird wieder wahr. Daher das zweimalige Schalten. Das Datum wird ja beim Zeitvergleich nicht berücksichtigt?

Danke und LG

ja, so ist es wohl. Du kannst neuerdings auch ein Fragezeichen davorsetzen, hier:
[?{sunset("REAL",0,"15:00","22:00")}-23:00], dann wird nur noch getriggert, wenn nexus4 den Status auf sbsent setzt.

Gruß

Damian

Spartacus · 02 Januar 2015, 09:37:44

Hallo,
Zunächst wünsche ich allen ein Frohes Neues Jahr und alles Gute für 2015.

Ich bin nun dabei, meine Neujahrs uns Silvester-DOIFs auszuwerrrten. So richtig hat das alles nicht geklappt und versuche nun den Fehler zu finden.

Code Auswählen

(
([16:30-22:30|56] or
 [16:30-22:30] and  [hl.01.Feiertag:tomorrow] ne "none" or
 [16:30-21:30|01234] and [hl.01.Feiertag:tomorrow] eq "none" or
 [16:30-02:00] and [?hl.01.Feiertag] eq "Silvester" 
) and [Tageslicht.dum] eq "dunkel") (set GA.ss.SA.Licht on) DOELSE (set GA.ss.SA.Licht off)

Irgendwie hatte ich erwartet, dass mein Licht bis 02:00 Uhr brennt, schaltete sich aber um 00:00:03 Uhr ab. Offenbar wird doch auf den Kalender und "Silvester" getriggert.
Das verstehe ich aber nicht.
Christian

Damian · 02 Januar 2015, 10:12:23

Zitat von: Spartacus am 02 Januar 2015, 09:37:44
Hallo,
Zunächst wünsche ich allen ein Frohes Neues Jahr und alles Gute für 2015.

Ich bin nun dabei, meine Neujahrs uns Silvester-DOIFs auszuwerrrten. So richtig hat das alles nicht geklappt und versuche nun den Fehler zu finden.
Code Auswählen Erweitern
( ([16:30-22:30|56] or [16:30-22:30] and [hl.01.Feiertag:tomorrow] ne "none" or [16:30-21:30|01234] and [hl.01.Feiertag:tomorrow] eq "none" or [16:30-02:00] and [?hl.01.Feiertag] eq "Silvester" ) and [Tageslicht.dum] eq "dunkel") (set GA.ss.SA.Licht on) DOELSE (set GA.ss.SA.Licht off)

Irgendwie hatte ich erwartet, dass mein Licht bis 02:00 Uhr brennt, schaltete sich aber um 00:00:03 Uhr ab. Offenbar wird doch auf den Kalender und "Silvester" getriggert.
Das verstehe ich aber nicht.
Christian

ja, die Bedingung wird ja von [hl.01.Feiertag:tomorrow] getriggert. Also auch bei diesen Angaben Fragezeichen davorstellen.

Gruß

Damian

Spartacus · 02 Januar 2015, 11:02:41

Hi Damian,
ok, (hoffentlich) verstanden! Das heißt, der Trigger vom Kalender steht über der Zeitangabe. Dann erklären sich auch einige andere Phänomene anderer DOIFs.

Jetzt habe ich in der folgenden Anweisung auch noch einen Fehler. Das Licht wurde gestern an Neujahr durch TK und LS eingeschaltet, aber nicht mehr ausgeschaltet. Ist auch klar, da ich das Abschalten in "cmd2" durch "Neujahr" verhindere. Das ist natürlich Quatsch! Es darf nur während 00:00 und 02:00 an Neujahr verhindert werden.

Code Auswählen

((([EG.ss.TK.Haustuer:buttons] eq "pressed") or 
   [EG.ss.LS.Eingang:buttons] eq "pressed") and [Tageslicht.dum] eq "dunkel" or 
   [00:00-02:00] and [?hl.01.Feiertag] eq "Neujahr")
   (set EI.ss.SA.Licht on)
DOELSEIF
 ([EG.ss.TK.Haustuer:buttons] eq "released" and [EG.ss.LS.Eingang:buttons] eq "released" and [?hl.01.Feiertag] ne "Neujahr" )
   (set EI.ss.SA.Licht off)
DOELSEIF 
  (([TK.Notaus.dum] eq "on" or [LS.Notaus.dum] eq "on") and [hl.01.Feiertag] ne "Neujahr")

Muss ich das dann so lösen?

Code Auswählen

DOELSEIF
 ([EG.ss.TK.Haustuer:buttons] eq "released" and [EG.ss.LS.Eingang:buttons] eq "released" and 
 !([00:00-02:00] and [?hl.01.Feiertag] ne "Neujahr") )
   (set EI.ss.SA.Licht off)

Beim Notaus (cmd3) dann identisch, damit auch das während 00:00 und 02:00 verhindert wird, richtig?

Christian