DOIF: neue Zeit-Features

[automatisierer]

Hallo,
ich hab seit dem ich heute Morgen ein Update gemacht habe ein Problem. Ich vermute es ist ein BUG, da ich mehrere ähnliche DOIF's verwende, die auch keine Probleme bereiten. An dem Problem DOIF habe ich auch nichts verändert.  Das Problem besteht darin, dass es nicht mehr auf CMD2 springt, durch anhängen eines DOELSE funktioniert es wieder. Habe mal ein list von beide Varianten gemacht.

list ohne DOELSE

Code Auswählen Erweitern

Internals:
   DEF        ([Schaltsteckdose_1_SenPwr] < 10) (set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 '')
   NAME       ueberw_kuehltruhe
   NR         192
   NTFY_ORDER 50-ueberw_kuehltruhe
   STATE      Alarm
   TYPE       DOIF
   Readings:
     2015-04-06 19:42:38   cmd_event       Schaltsteckdose_1_SenPwr
     2015-04-06 19:42:38   cmd_nr          1
     2015-04-06 19:58:21   e_Schaltsteckdose_1_SenPwr_STATE 113.78
     2015-04-06 19:42:38   state           Alarm
     2015-04-06 19:45:19   wait_timer      06.04.2015 22:45:19 cmd_1 Schaltsteckdose_1_SenPwr
   Condition:
     0          InternalDoIf('Schaltsteckdose_1_SenPwr','STATE','') < 10
   Devices:
     0           Schaltsteckdose_1_SenPwr
     all         Schaltsteckdose_1_SenPwr
   Do:
     0          set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 ''
   Helper:
     last_timer 0
     sleepdevice Schaltsteckdose_1_SenPwr
     sleeptimer 0
   Internals:
     0           Schaltsteckdose_1_SenPwr:STATE
     all         Schaltsteckdose_1_SenPwr:STATE
   Itimer:
   Readings:
   State:
   Timerfunc:
   Trigger:
Attributes:
   cmdState   Alarm|laeuft
   do         always
   room       __Befehle
   wait       10800

die Bedingung ist nicht wahr, aber das DOIF bleibt bei cmd 1

nun das list mit DOELSE

Code Auswählen Erweitern

Internals:
   DEF        ([Schaltsteckdose_1_SenPwr] < 10) (set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 '') DOELSE
   NAME       ueberw_kuehltruhe
   NR         192
   NTFY_ORDER 50-ueberw_kuehltruhe
   STATE      laeuft
   TYPE       DOIF
   Readings:
     2015-04-06 20:00:52   cmd_event       Schaltsteckdose_1_SenPwr
     2015-04-06 20:00:52   cmd_nr          2
     2015-04-06 20:00:52   e_Schaltsteckdose_1_SenPwr_STATE 110.4
     2015-04-06 20:00:52   state           laeuft
   Condition:
     0          InternalDoIf('Schaltsteckdose_1_SenPwr','STATE','') < 10
   Devices:
     0           Schaltsteckdose_1_SenPwr
     all         Schaltsteckdose_1_SenPwr
   Do:
     0          set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 ''
     1
   Helper:
     last_timer 0
     sleeptimer -1
   Internals:
     0           Schaltsteckdose_1_SenPwr:STATE
     all         Schaltsteckdose_1_SenPwr:STATE
   Itimer:
   Readings:
   State:
   Timerfunc:
   Trigger:
Attributes:
   cmdState   Alarm|laeuft
   do         always
   room       __Befehle
   wait       10800

hier ist das DOIF auf cmd 2 gesprungen, so wie es mMn richtig ist.

Wie gesagt habe ich mehrere DOIF's die ähnliche Aufgaben erfüllen, fertig Meldung für Waschmaschine und Trockner, beide funktionieren auch ohne ein DOELSE.

Gruß
Ingo

[Damian]

Hallo,
ich hab seit dem ich heute Morgen ein Update gemacht habe ein Problem. Ich vermute es ist ein BUG, da ich mehrere ähnliche DOIF's verwende, die auch keine Probleme bereiten. An dem Problem DOIF habe ich auch nichts verändert.  Das Problem besteht darin, dass es nicht mehr auf CMD2 springt, durch anhängen eines DOELSE funktioniert es wieder. Habe mal ein list von beide Varianten gemacht.

list ohne DOELSE

Code Auswählen Erweitern

Internals:
   DEF        ([Schaltsteckdose_1_SenPwr] < 10) (set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 '')
   NAME       ueberw_kuehltruhe
   NR         192
   NTFY_ORDER 50-ueberw_kuehltruhe
   STATE      Alarm
   TYPE       DOIF
   Readings:
     2015-04-06 19:42:38   cmd_event       Schaltsteckdose_1_SenPwr
     2015-04-06 19:42:38   cmd_nr          1
     2015-04-06 19:58:21   e_Schaltsteckdose_1_SenPwr_STATE 113.78
     2015-04-06 19:42:38   state           Alarm
     2015-04-06 19:45:19   wait_timer      06.04.2015 22:45:19 cmd_1 Schaltsteckdose_1_SenPwr
   Condition:
     0          InternalDoIf('Schaltsteckdose_1_SenPwr','STATE','') < 10
   Devices:
     0           Schaltsteckdose_1_SenPwr
     all         Schaltsteckdose_1_SenPwr
   Do:
     0          set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 ''
   Helper:
     last_timer 0
     sleepdevice Schaltsteckdose_1_SenPwr
     sleeptimer 0
   Internals:
     0           Schaltsteckdose_1_SenPwr:STATE
     all         Schaltsteckdose_1_SenPwr:STATE
   Itimer:
   Readings:
   State:
   Timerfunc:
   Trigger:
Attributes:
   cmdState   Alarm|laeuft
   do         always
   room       __Befehle
   wait       10800

die Bedingung ist nicht wahr, aber das DOIF bleibt bei cmd 1

nun das list mit DOELSE

Code Auswählen Erweitern

Internals:
   DEF        ([Schaltsteckdose_1_SenPwr] < 10) (set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 '') DOELSE
   NAME       ueberw_kuehltruhe
   NR         192
   NTFY_ORDER 50-ueberw_kuehltruhe
   STATE      laeuft
   TYPE       DOIF
   Readings:
     2015-04-06 20:00:52   cmd_event       Schaltsteckdose_1_SenPwr
     2015-04-06 20:00:52   cmd_nr          2
     2015-04-06 20:00:52   e_Schaltsteckdose_1_SenPwr_STATE 110.4
     2015-04-06 20:00:52   state           laeuft
   Condition:
     0          InternalDoIf('Schaltsteckdose_1_SenPwr','STATE','') < 10
   Devices:
     0           Schaltsteckdose_1_SenPwr
     all         Schaltsteckdose_1_SenPwr
   Do:
     0          set pushIngo msg 'Warnung' 'Kuehltruhe hat seit 3 Stunden nicht mehr gelaufen' '' 1 ''
     1
   Helper:
     last_timer 0
     sleeptimer -1
   Internals:
     0           Schaltsteckdose_1_SenPwr:STATE
     all         Schaltsteckdose_1_SenPwr:STATE
   Itimer:
   Readings:
   State:
   Timerfunc:
   Trigger:
Attributes:
   cmdState   Alarm|laeuft
   do         always
   room       __Befehle
   wait       10800

hier ist das DOIF auf cmd 2 gesprungen, so wie es mMn richtig ist.

Wie gesagt habe ich mehrere DOIF's die ähnliche Aufgaben erfüllen, fertig Meldung für Waschmaschine und Trockner, beide funktionieren auch ohne ein DOELSE.

Gruß
Ingo

ja, das habe ich wegen eines anderen Problems geändert, siehe hier:

http://forum.fhem.de/index.php/topic,30847.msg281484.html#msg281484

do always macht hier, so wie ich es gerade überblicke keinen Sinn. Lösche es, dann funktioniert es schon. Ansonsten hast du die von mir angedachte Lösung für "sinnvolle" do always Fälle ohne DOELSE mit der alleinigen DOELSE-Angabe schon selbst richtig erkannt.

Gruß

Damian

[Toto1973]

Ich habe ja meine DOIF-Anweisung für meine WandUhr abgeändert nach den neusten Anpassungen.

Code Auswählen Erweitern

([Wanduhr_dummy:state] eq "on" and [:00]) ({WandUhr()})
DOELSEIF ([:15] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_15.mp3 -volume 83 −really−quiet &")})
DOELSEIF ([:30] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_30.mp3 -volume 83 −really−quiet &")})
DOELSEIF ([:45] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_45.mp3 -volume 83 −really−quiet &")})
Was mir nun aufgefallen ist, das mein FHEM nun immer ein save haben möchte. Könnte das mit der Umstellung zu tun haben?
Ich wüsste nämlich sonst nichts, was ich geändert hätte...

[Damian]

Ich habe ja meine DOIF-Anweisung für meine WandUhr abgeändert nach den neusten Anpassungen.

Code Auswählen Erweitern

([Wanduhr_dummy:state] eq "on" and [:00]) ({WandUhr()})
DOELSEIF ([:15] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_15.mp3 -volume 83 −really−quiet &")})
DOELSEIF ([:30] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_30.mp3 -volume 83 −really−quiet &")})
DOELSEIF ([:45] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_45.mp3 -volume 83 −really−quiet &")})
Was mir nun aufgefallen ist, das mein FHEM nun immer ein save haben möchte. Könnte das mit der Umstellung zu tun haben?
Ich wüsste nämlich sonst nichts, was ich geändert hätte...

Dann müsste sich hier etwas an der Konfiguration ändert - das ist hier nicht der Fall. Ich habe den Befehl bei mir definiert. WandUhr und mplayer führt zwar zu einer Fehlermeldung, weil es die bei mir nicht gibt. Bei Save Config wird das Fragezeichen aber nicht aktiv.

Gruß

Damian

[kvo1]

Was mir nun aufgefallen ist, das mein FHEM nun immer ein save haben möchte. Könnte das mit der Umstellung zu tun haben?
Ich wüsste nämlich sonst nichts, was ich geändert hätte...

Bei mir kommt das z.B. durch die Einbindung des calendar bzw. calview , hier werden innerhalb der readingsgroup über at
die Daten aktualisiert !

[Toto1973]

Danke für den Hinweis!
Da muss ich mal genauer nachsehen, wo das her kommt!

[FunkOdyssey]

Können diese neuen Zeit-Features eigentlich auch dazu genutzt werden, um verschiedene Zeitraster am Tag zu benutzen?


Ich starte meine Zirkulationspumpe folgendermaßen:

Code Auswählen Erweitern


([+00:10]) (set powerMeter1_switch on-for-timer 120)


Ich möchte diesen Abstand aber in der Nacht erhöhen. Also muss ich Zeitraum und Zeitraster in der Bedingung kombinieren. Geht das?

[Damian]

Können diese neuen Zeit-Features eigentlich auch dazu genutzt werden, um verschiedene Zeitraster am Tag zu benutzen?


Ich starte meine Zirkulationspumpe folgendermaßen:

Code Auswählen Erweitern


([+00:10]) (set powerMeter1_switch on-for-timer 120)


Ich möchte diesen Abstand aber in der Nacht erhöhen. Also muss ich Zeitraum und Zeitraster in der Bedingung kombinieren. Geht das?

Schon etwas ausprobiert?

Bsp:

set Zeit 00:15

([+[Zeit]])(...)

oder

set Zeit 900

([+[Zeit]])(...)

oder

set Zeit +00:15

([[Zeit]]) (...)


oder ausgerichtet

set Zeit +:15

([[Zeit]]) (...)


Es gibt noch mehr Möglichkeiten mit runden Klammern (siehe Berechnung von Zeit in der Commandref), aber das sollte erst mal reichen.

such dir also etwas aus

Edit: Dummy Zeit kannst du natürlich mit einem separaten DOIF zeitgesteuert setzen.

Gruß

Damian

[FunkOdyssey]

Ich habe es quick&dirty folgendermaßen ausprobiert:

Code Auswählen Erweitern


(
[22:00-06:00] and [+00:30]
)
(set powerMeter1_switch on-for-timer 150)
DOELSE
(set powerMeter1_switch on)


Muss noch schön gemacht werden. Aber es scheint zu funktionieren.

[flurin]

Ich habe ja meine DOIF-Anweisung für meine WandUhr abgeändert nach den neusten Anpassungen.

Code Auswählen Erweitern

([Wanduhr_dummy:state] eq "on" and [:00]) ({WandUhr()})
DOELSEIF ([:15] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_15.mp3 -volume 83 −really−quiet &")})
DOELSEIF ([:30] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_30.mp3 -volume 83 −really−quiet &")})
DOELSEIF ([:45] and [Wanduhr_dummy:state] eq "on") ({system ("mplayer /opt/fhem/Sound/BigBen_45.mp3 -volume 83 −really−quiet &")})
Was mir nun aufgefallen ist, das mein FHEM nun immer ein save haben möchte. Könnte das mit der Umstellung zu tun haben?
Ich wüsste nämlich sonst nichts, was ich geändert hätte...

Deine WandUhr lässt mich nicht in Ruhe schlafen 

ich hab's bei mir so vereinfacht:

Code Auswählen Erweitern


define di_wall_clock DOIF ([+:15]) ({system("mplayer /opt/fhem/Sound/BigBen_".$min.".mp3 -volume 83 −really−quiet &")})
attr di_wall_clock do always


Gruss
flurin

[Toto1973]

Ich muss hier auch mal wieder was nachfragen.
Seit Anfang an mache ich mich mit dieser "Schaltung" hier rum:

Code Auswählen Erweitern

([09:01-20:00] and [sz_Waesche_trocknen] eq "on" and [?Jahreszeit] eq "Winter") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([Jahreszeit] eq "Sommer") (set sz_Heizung desiredTemperature off)
DOELSEIF ([03:30-05:00|8] and [geofancy:currLoc_Toto] eq "Home" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Frueh") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([07:45-09:00|8] and [geofancy:currLoc_Toto] eq "Home" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Mittel") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([09:01-11:00] and [?sz_Waesche_trocknen] eq "off" and [?Jahreszeit] eq "Winter" and [geofancy:currLoc_Toto] eq "Home") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([11:01-18:00] and [?sz_Waesche_trocknen] eq "off" and [?Technoclub] eq "nein" and [?Jahreszeit] eq "Winter" and [geofancy:currLoc_Toto] eq "Home") (set sz_Heizung desiredTemperature 20)
DOELSEIF ([14:00-18:00|7] and [?sz_Waesche_trocknen] eq "off" and [Technoclub] eq "ja" and [?Jahreszeit] eq "Winter" and [geofancy:currLoc_Toto] eq "Home") (set sz_Heizung desiredTemperature 20)
DOELSE (set sz_Heizung desiredTemperature 17)

Es soll also zu verschiedenen Zeiten ein Heinzkörper gesteuert werden. Dies geschieht abhängig von verschiedene Faktoren (Dummys). Soweit funktioniert das auch im Teil ganz gut.
Allerdings springt mir der DOIF immer wieder in die DOELSE Bedienung, obwohl andere Bedienungen passen würde.
Also immer dann, wenn eine neue Zeit triggert, funktioniert es nicht mehr so, wie eigentlich gewollt.

Zu meinem Verständnis:
Ist es so, das DOIF zu erst die erste Bedingung abfragt (hier also die erste Zeile) und wenn die zutrifft, dann fragt es den Rest nicht mehr ab?
Weil ich vermute, das genau das nicht passiert!
Sprich, er fragt immer alles ab!
Ist das so richtig und wenn ja, kann man das nicht ändern?

Ergänzung:
Ich stelle mir das so vor:
Bedingung 1 wird durch die Uhrzeit und den Wäsche_trocknen Dummy wahr, dann ruht DOIF bis entweder die Endzeit erreicht ist (im Beispiel 20 Uhr) oder sich der Zustand des Wäsche_trocknen Dummy ändert.
Alle anderen Timer würde quasi ignoriert werden.
Das ganze könnte ja durch ein Attribut, das man setzen kann, aktiviert werden.
Das würde solche komplexen Steuerungen etwas übersichtlicher machen.

[Damian]

Ich muss hier auch mal wieder was nachfragen.
Seit Anfang an mache ich mich mit dieser "Schaltung" hier rum:

Code Auswählen Erweitern

([09:01-20:00] and [sz_Waesche_trocknen] eq "on" and [?Jahreszeit] eq "Winter") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([Jahreszeit] eq "Sommer") (set sz_Heizung desiredTemperature off)
DOELSEIF ([03:30-05:00|8] and [geofancy:currLoc_Toto] eq "Home" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Frueh") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([07:45-09:00|8] and [geofancy:currLoc_Toto] eq "Home" and [?Jahreszeit] eq "Winter" and [?Schicht_dummy] eq "Mittel") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([09:01-11:00] and [?sz_Waesche_trocknen] eq "off" and [?Jahreszeit] eq "Winter" and [geofancy:currLoc_Toto] eq "Home") (set sz_Heizung desiredTemperature 22)
DOELSEIF ([11:01-18:00] and [?sz_Waesche_trocknen] eq "off" and [?Technoclub] eq "nein" and [?Jahreszeit] eq "Winter" and [geofancy:currLoc_Toto] eq "Home") (set sz_Heizung desiredTemperature 20)
DOELSEIF ([14:00-18:00|7] and [?sz_Waesche_trocknen] eq "off" and [Technoclub] eq "ja" and [?Jahreszeit] eq "Winter" and [geofancy:currLoc_Toto] eq "Home") (set sz_Heizung desiredTemperature 20)
DOELSE (set sz_Heizung desiredTemperature 17)

Es soll also zu verschiedenen Zeiten ein Heinzkörper gesteuert werden. Dies geschieht abhängig von verschiedene Faktoren (Dummys). Soweit funktioniert das auch im Teil ganz gut.
Allerdings springt mir der DOIF immer wieder in die DOELSE Bedienung, obwohl andere Bedienungen passen würde.
Also immer dann, wenn eine neue Zeit triggert, funktioniert es nicht mehr so, wie eigentlich gewollt.

Zu meinem Verständnis:
Ist es so, das DOIF zu erst die erste Bedingung abfragt (hier also die erste Zeile) und wenn die zutrifft, dann fragt es den Rest nicht mehr ab?
Weil ich vermute, das genau das nicht passiert!
Sprich, er fragt immer alles ab!
Ist das so richtig und wenn ja, kann man das nicht ändern?

Zitat aus der Commandref:

Die Angaben werden immer von links nach rechts abgearbeitet. Es wird immer nur ein Kommando ausgeführt, und zwar das erste, für das die dazugehörige Bedingung in der abgearbeiteten Reihenfolge wahr ist. Hinzu kommt, dass nur die Bedingungen überprüft werden, die zum ausgelösten Event auch das Device beinhalten.

Das gilt insb. auch für Zeittrigger, wenn also z. B. um 03:30 die dritte Bedingung getriggert wird, wird auch nur diese zu diesem Zeitpunkt geprüft und wenn sie nicht stimmt, dann wird der DOELSE-Fall ausgeführt.
Ein Problem kann es bei 09:01 Uhr geben, denn das Modul wird um diese Zeit zweimal getriggert, dabei ist die zeitliche Abfolge der Überprüfung nicht sichergestellt. Es kann also sein, dass zuerst die erste Bedingung geprüft wird und dann die fünfte, es kann aber auch sein dass zuerst die fünfte geprüft wird und dann erst die erste.

Wenn man sicherstellen will, dass zuerst die erste Bedingung geprüft wird und dann die fünfte, dann sollte man bei der fünften statt 09:01... einen etwas späteren Zeitpunkt angeben z. B. 09:01:01....

Zukünftig wird die Reihenfolge der Abarbeitung bei gleicher Zeit sichergestellt werden (steht schon auf der todo-Liste).

Gruß

Damian

[Toto1973]

Das Problem ist aber noch die Zeitspanne oder?
Wenn eine Bedinung von 9 bis 11 Uhr geht, eine andere Bedingung von 10 bis 12 Uhr, dann wird um 10 Uhr geprüft und wenn die Bedinung nicht wahr ist, fällt DOIF auf die DOELSE Bedinung, richtig?
Logisch wäre ja dann aber, das Bedingung 1 weiter Bestand hätte, bis 11 Uhr.

[Damian]

Das Problem ist aber noch die Zeitspanne oder?
Wenn eine Bedinung von 9 bis 11 Uhr geht, eine andere Bedingung von 10 bis 12 Uhr, dann wird um 10 Uhr geprüft und wenn die Bedinung nicht wahr ist, fällt DOIF auf die DOELSE Bedinung, richtig?
Logisch wäre ja dann aber, das Bedingung 1 weiter Bestand hätte, bis 11 Uhr.

ja, da könnte man überlegen,  ob man Attribut-gesteuert bei irgendeinem Zeittrigger die Überprüfung aller Bedingungen vornimmt - ich kann aber z. Zt. die Konsequenzen einer solchen Vorgehensweise noch nicht absehen.

Es ist immer kritisch mehrere DOELSIF-Fälle mit Zeitintervallen und einem DOELSE-Fall anzugeben. Weil man höllisch auf Zeitüberschneidungen achten muss und der DOELSE-Fall öfters zum Zuge kommt als man denkt. In solchen Fällen würde ich ohne Intervalle arbeiten und stattdessen nur mit Zeitpunkten arbeiten, denn diese sind wesentlich unkritischer zu handhaben, weil sie nur zum Triggerzeitpunkt wahr sind und sonst nicht - da hat man weniger Probleme mit irgendwelchen Überschneidungen bzw. Abhängigkeiten.

Bei dir würde sich damit die Anzahl der Fälle auf drei reduzieren temp 22, temp 20 und temp 17. In der entsprechenden Bedingung würde ich nur Zeitpunkte angeben, ab wann die Temperatur gelten soll und keinen DOELSE-Fall angeben.

Gruß

Damian

[Toto1973]

Vielen Dank für die Antwort. Ich werde das Ganze mal umbauen