DOIF neue Features (Sleep-Alternative)

Mumpitz · 23 September 2015, 19:12:24

Hallo Damian

Danke für Deine Antwort. Aus meiner Sicht macht es keinen Sinn, den Sensorwert als nicht triggerndes Argument zu definieren. Ich will ja genau das, dass aufgrund der Helligkeit das entsprechende Event (Beschattung on oder off) ausgelöst wird.

Gibt es eine andere Möglichkeit???
Oder muss ich schlussendlich zwei verschiedene DOIF's machen? (was ich allerdings nicht will)

Merci!

Damian · 23 September 2015, 20:47:00

Zitat von: Mumpitz am 23 September 2015, 19:12:24
Hallo Damian

Danke für Deine Antwort. Aus meiner Sicht macht es keinen Sinn, den Sensorwert als nicht triggerndes Argument zu definieren. Ich will ja genau das, dass aufgrund der Helligkeit das entsprechende Event (Beschattung on oder off) ausgelöst wird.

Gibt es eine andere Möglichkeit???
Oder muss ich schlussendlich zwei verschiedene DOIF's machen? (was ich allerdings nicht will)

Merci!

Hast du denn geschaut, wer da die Bedingung so kurzfristig unwahr werden lässt? Der Multisensor kann es wohl nicht sein.

Gruß

Damian

Mumpitz · 23 September 2015, 21:10:13

Doch, es ist der MultiSensor. Also zumindest die Zeit stimmt überein!

Aber ich frage mich schon warum der reinspielt, beim Beschattung_off frage ich den gar nicht ab! Wieso kann der den Timer wieder aufheben?

Code Auswählen

2015-09-22_13:28:34 di_SoSchu_OG wait_timer: no timer
2015-09-22_13:28:34 di_SoSchu_EG wait_timer: no timer
2015-09-22_13:28:15 di_SoSchu_OG wait_timer: 22.09.2015 14:08:15 cmd_2 Sensor_Licht_Sued
2015-09-22_13:28:15 di_SoSchu_EG wait_timer: 22.09.2015 14:08:15 cmd_3 Sensor_Licht_Sued

Code Auswählen

2015-09-22_13:28:34 Multisensor_Ost humidity: 40
2015-09-22_13:28:34 Multisensor_Ost temperature: 26
2015-09-22_13:28:34 Multisensor_Ost 7101
2015-09-22_13:28:34 Multisensor_Ost lux: 7101

Brockmann · 23 September 2015, 23:42:38

Zitat von: Mumpitz am 23 September 2015, 21:10:13
Doch, es ist der MultiSensor. Also zumindest die Zeit stimmt überein!
Aber ich frage mich schon warum der reinspielt, beim Beschattung_off frage ich den gar nicht ab! Wieso kann der den Timer wieder aufheben?

Der Multisensor triggert, aber die Bedingungen, in denen er enthalten ist, sind nicht wahr, also geht es zum DOELSE-Fall. Das hebt den Timer auf.

Ich würde versuchen, ohne leeres DOELSE auszukommen. So nach dem Prinzip:
DOIF (Variante1)(Beschattung off)
DOELSEIF (Variante2)(Beschattung off)
DOELSE(Beschattung on)

Du kannst on und off auch vertauschen, aber entscheidend ist, dass wenn eine der Bedingungen erfüllt ist, Aktion A ausgeführt wird und wenn keine der Bedingungen erfüllt ist, Aktion B.
Dann wäre das DOIF sozusagen immer in einem wohldefinierten Zustand. Ich weiß nicht, ob das in Deinem Szenario möglich ist. Aber irgendwie sollte man es hinbekommen.

Und wirklich nur die Bedingungen triggern lassen, wo es unbedingt nötig ist. Das reduziert die Gefahr solcher Seiteneffekte.

Damian · 24 September 2015, 08:26:10

Zitat von: Mumpitz am 23 September 2015, 21:10:13
Doch, es ist der MultiSensor. Also zumindest die Zeit stimmt überein!

Aber ich frage mich schon warum der reinspielt, beim Beschattung_off frage ich den gar nicht ab! Wieso kann der den Timer wieder aufheben?

Code Auswählen Erweitern
2015-09-22_13:28:34 di_SoSchu_OG wait_timer: no timer 2015-09-22_13:28:34 di_SoSchu_EG wait_timer: no timer 2015-09-22_13:28:15 di_SoSchu_OG wait_timer: 22.09.2015 14:08:15 cmd_2 Sensor_Licht_Sued 2015-09-22_13:28:15 di_SoSchu_EG wait_timer: 22.09.2015 14:08:15 cmd_3 Sensor_Licht_Sued

Code Auswählen Erweitern
2015-09-22_13:28:34 Multisensor_Ost humidity: 40 2015-09-22_13:28:34 Multisensor_Ost temperature: 26 2015-09-22_13:28:34 Multisensor_Ost 7101 2015-09-22_13:28:34 Multisensor_Ost lux: 7101

Der Multisensor führt zu einer wahren Bedingung, zurückgesetzt wird dieser Zustand vermutlich aber durch einen anderen (zyklischen) Trigger.

Ich arbeite bei mehreren Bedingung selten mit DOELSE, vor allem nicht bei zyklischen Triggern, weil man schnell etwas übersieht, was zu diesem Fall führt.

Deswegen wird ein Sonst-Zustand bei mehreren Bedingungen nur bei Angabe von DOELSE gesetzt und sonst nicht. Es ist also ein gewolltes Features und eben kein Bug.

Gruß

Damian

Toto1973 · 25 September 2015, 11:11:54

Ich habe da leider auch mal wieder ein Problem.
Ich habe mal meinen Wecker als DOIF umgebaut. Der Wochentag sowie die Weckzeit, werden über ein Dummy bestimmt.

Code Auswählen

define wecker DOIF ([([wakeUp_dummy]-[0:20])|[tag]]) ((set sz_LED_Schrank HSV 240,100,100))

Das Dummy für die Weckzeit sieht so aus:

Code Auswählen

define wakeUp_dummy dummy
attr wakeUp_dummy alias Weckzeit
attr wakeUp_dummy group Weckereinstellung
attr wakeUp_dummy icon time_timer@yellow
attr wakeUp_dummy room Schlafzimmer
attr wakeUp_dummy setList state:time
attr wakeUp_dummy webCmd state

Als State liefert es eine Uhrzeit (11:35).

Das Dummy für den Wochentag sieht so aus:

Code Auswählen

define tag dummy
attr tag alias Wecker Tag
attr tag eventMap 1:Montag 2:Dienstag 3:Mittwoch 4:Donnerstag 5:Freitag 6:Samstag 0:Sonntag 7:Wochenende 8:Werktags 9:aus
attr tag group Weckereinstellung
attr tag icon time_calendar@yellow
attr tag room Schlafzimmer
attr tag setList state:Montag,Dienstag,Mittwoch,Donnerstag,Freitag,Samstag,Sonntag,Wochende,Werktags,aus
attr tag webCmd state

Als State habe ich hier die entsprechende zahl (für Mittwoch 3).

Im DOIF selbst bei den Uhrzeiten steht das hier: timer_1_c1 26.09.2015 11:05:00|[tag]
Sollte da nicht die Zahl aus dem Dummy angezeigt werden?

Die Commandref sagt ja das hier:

Code Auswählen

Anwendungsbeispiel: Der Wochentag soll über einen Dummy bestimmt werden.

define dummy Wochentag
set Wochentag 135

define di_radio DOIF ([06:30|[Wochentag]] (set radio on) DOELSEIF ([07:30|[Wochentag]]) (set radio off)

Toto1973 · 25 September 2015, 11:30:33

So, manchmal findet man auch selbst den Fehler!

Da ich ja mit einer SetList und der EventMap arbeitet, wird der interne Status des Dummys auf den Namen des Wochentages gesetzt. Dadurch kann die Zeitangabe nix damit anfangen!
Beispiel: ([11:25|Montag])

Also muss ich im DOIF zum Dummyname auch noch :state anhängen, damit er das reading state verwendet!
Hier mal der Dummy:

Code Auswählen

 tag Internals
NAME tag
NR 65
STATE Freitag
TYPE dummy
Readings state 5

Und hier die funktionierende DOIF:

Code Auswählen

define wecker DOIF ([([wakeUp_dummy]-[0:20])|[tag:state]]) ((set sz_LED_Schrank HSV 240,100,100))

Vielleicht wäre das auch in der Commandref als Ergänzung gut aufgehoben!?

Toto1973 · 25 September 2015, 11:44:56

Alles Gute ist 3...

Ich hätte da noch eine Idee!
Und zwar geht es um Zeiten. Wenn man {sunrise(0,"03:00","10:00")} benutzt, kann man ja durch die Zeitangaben den Zeitraum eingrenzen. So etwas würde ich mir auch für Dummys mit Zeitangaben wünschen.
Hintergrund ist folgender:
Ich habe eine DOIF, die mir optisch Bescheid gibt, wenn die Luftfeuchtigkeit in der Wohnung zu hoch wird. Diese soll aber nur in einem Bestimmten Zeitraum aktiv sein. Dieser Zeitraum soll aber auch von der Weckzeit abhängig sein.
Liegt nun quasi die Weckzeit außerhalb des Zeitraumes, dann soll das DOIF erst aktiv werden, wenn der Zeitraum erreicht ist.
Liegt die Weckzeit innerhalb des Zeitraumes, dann soll das DOIF ab der Weckzeit aktiv werden.

Beispiel:

Code Auswählen

define feuchte DOIF ({[weckzeit_dummy](0,"09:00","23:00")} and [wz_Temperatur:humidity]>57) (set LED_Lampe on)

Wäre so etwas machbar?

Brockmann · 25 September 2015, 12:19:10

Zitat von: Toto1973 am 25 September 2015, 11:44:56
Beispiel:
Code Auswählen Erweitern
define feuchte DOIF ({[weckzeit_dummy](0,"09:00","23:00")} and [wz_Temperatur:humidity]>57) (set LED_Lampe on)

Wäre so etwas machbar?

Reicht dafür nicht einfach eine zusätzliche Bedingung?

Code Auswählen


define feuchte DOIF ({[weckzeit_dummy]} and [09:00-23:00] and [wz_Temperatur:humidity]>57) (set LED_Lampe on)

Toto1973 · 25 September 2015, 15:04:15

Zitat von: Brockmann
Reicht dafür nicht einfach eine zusätzliche Bedingung?
Code Auswählen Erweitern
define feuchte DOIF ({[weckzeit_dummy]} and [09:00-23:00] and [wz_Temperatur:humidity]>57) (set LED_Lampe on)

In dem Fall würde das DOIF nur "schalten" wenn die Weckzeit innerhalb dem Zeitraum 9-23 Uhr liegt.
Liegt die Weckzeit aber außerhalb des Zeitraumes, würde nichts schalten, weil dann die Bedingung nie wahr wird!

Damian · 25 September 2015, 18:42:09

Zitat von: Toto1973 am 25 September 2015, 11:44:56
Alles Gute ist 3...

Ich hätte da noch eine Idee!
Und zwar geht es um Zeiten. Wenn man {sunrise(0,"03:00","10:00")} benutzt, kann man ja durch die Zeitangaben den Zeitraum eingrenzen. So etwas würde ich mir auch für Dummys mit Zeitangaben wünschen.
Hintergrund ist folgender:
Ich habe eine DOIF, die mir optisch Bescheid gibt, wenn die Luftfeuchtigkeit in der Wohnung zu hoch wird. Diese soll aber nur in einem Bestimmten Zeitraum aktiv sein. Dieser Zeitraum soll aber auch von der Weckzeit abhängig sein.
Liegt nun quasi die Weckzeit außerhalb des Zeitraumes, dann soll das DOIF erst aktiv werden, wenn der Zeitraum erreicht ist.
Liegt die Weckzeit innerhalb des Zeitraumes, dann soll das DOIF ab der Weckzeit aktiv werden.

Beispiel:
Code Auswählen Erweitern
define feuchte DOIF ({[weckzeit_dummy](0,"09:00","23:00")} and [wz_Temperatur:humidity]>57) (set LED_Lampe on)

Wäre so etwas machbar?

ja.

in myÚtils.pm:

Code Auswählen


sub startzeit($$$)
{
  my ($weckzeit, $anfang, $ende) = @_;
  if ($weckzeit lt $anfang or $weckzeit gt $ende) { 
    return $anfang;
  } else  {
    return $weckzeit;
  }
}

Code Auswählen

define feuchte DOIF ([{startzeit(Value("weckzeit_dummy"),"09:00","23:00")}-23:00] and [wz_Temperatur:humidity]>57) (set LED_Lampe on)

Gruß

Damian

Toto1973 · 25 September 2015, 20:54:53

Du bist einfach nur genial!
Werde ich gleich mal testen

Dankeschön!

dominik · 26 September 2015, 10:01:38

Hi Damian,
ist es möglich über DOIF ein Datum abzufragen? Ich möchte ein DOIF schreiben, welches 6h vor Ende meines Urlaubs (CALVIEW) den Staugsaugerroboter startet.
Wie man die -6h rechnet, habe ich herausgefunden, aber für eine gezielte Datumsabfrage konnte ich nichts finden. Ein Umweg wäre wohl über $year, $month, $day zu gehen und das abzufragen.

moonsorrox hatte hier eine ähnliche Frage die wohl untergegangen ist (http://forum.fhem.de/index.php/topic,39070.msg335728.html#msg335728).

Damian · 26 September 2015, 10:20:48

Zitat von: dominik am 26 September 2015, 10:01:38
Hi Damian,
ist es möglich über DOIF ein Datum abzufragen? Ich möchte ein DOIF schreiben, welches 6h vor Ende meines Urlaubs (CALVIEW) den Staugsaugerroboter startet.
Wie man die -6h rechnet, habe ich herausgefunden, aber für eine gezielte Datumsabfrage konnte ich nichts finden. Ein Umweg wäre wohl über $year, $month, $day zu gehen und das abzufragen.

moonsorrox hatte hier eine ähnliche Frage die wohl untergegangen ist (http://forum.fhem.de/index.php/topic,39070.msg335728.html#msg335728).

Datumsangaben sind bisher nicht programmiert. Ich habe allerdings folgende Variablen zum Abfragen in der Bedingung vorgesehen:

$sec,$min,$hour,$mday,$month,$year,$wday,$yday,$isdst sowie $hms und $hm.

Gruß

Damian

Joesky · 26 September 2015, 12:26:18

Wie kann ich mit Hilfe von DOIF eine Methode aus 99_myUtils.pm aufrufen? Ich probiere es so:

Code Auswählen

define tkDoorOpen DOIF ([Eingangstuer] eq "open") ({ DebianMail('email@server.de', 'Tür ist geöffnet!', '');; })

Im Log bekomme ich den folgenden Fehler:

ZitattkDoorOpen: { DebianMail('email@server.de', 'Tür ist geöffnet!', ''); }: Unknown command {, try help.
Unknown command }, try help.

Wenn ich

Code Auswählen

{ DebianMail('email@server.de', 'Tür ist geöffnet!', '');; }
in fhem direkt ausführe, wird eine eMail ohne Fehler verschickt.